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(54) Cryptographic data security in a secured computer system 



(57) A data communication system providing for the 
secure transfer and sharing of data via a local area net- 
work and/or a wide area network. The system includes 
a secure processing unit which communicates with a 
personal keying device and a crypto media controller 
attached to a user's workstation. The communication 
between these processing elements generates a variety 
of data elements including keys, identifiers and 
attributes. The data elements are used to identify and 
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authenticate the user, assign user security access 
rights and privileges, and assign media and device 
attributes to a data access device according to a prede- 
fined security policy. The data elements are manipu- 
lated, combined, protected and distributed through the 
network to the appropriate data access devices, which 
prevents the user from obtaining unauthorized data. 
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Description 

Field of the Invention 

This invention relates generally to data communica- 
tion systems, and more specifically to secure data 
processing on a data communication system. 

Background of the Invention 

Data Enclave 

Individuals working in a departmental computing 
environment typically have a substantial amount of 
computing power on their desks in the form of personal 
computers and workstations. A workstation has a com- 
putational subsystem, keyboard, and display for user 
interaction, and typically substantial amounts of local 
data storage in the form of fixed and removable media. 

In order for the individual in the departmental com- 
puting environment to interact and share data, their 
workstations are typically attached to a local area net- 
work (LAN) which permits the transfer of data files and 
electronic mail between the workstations, in addition, 
"servers" may be attached to the LAN to provide spe- 
cialized services, such as the management of central- 
ized databases, which are not practical for individual 
workstations. 

Departmental computing environments are typi- 
cally members of a larger organization or have other 
reasons to communicate with computing facilities out- 
side themselves. They therefore make use of a special 
kind of server, called a "gateway", to gain access to a 
wide area network (WAN). WANs are often intercon- 
nected (called "internetting") to provide world-wide data 
transmission paths. 

Departmental Computing Environment 

A typical overall departmental computing environ- 
ment is shown in Figure 1 . In the departmental compu- 
ter environment 1, large amounts of valuable data is 
stored on magnetic or other electronic Media 2, 4 for 
processing in the Workstations 10 and file servers (not 
shown). This media offers the benefits of compact stor- 
age, easy retrieval, and in the case of removable Media 
4 (e.g., "diskettes"), convenient sharing and distribution. 

In addition, data is transmitted freely around the 
Local Area Network 12 and occasionally through a 
Gateway 14 to the Wide Area Network 16 and Remote 
Sites 18. This transmission is necessary in order for the 
organization performing departmental computing to 
perform its internal work and interact with the outside 
world. 

There is also a requirement that certain operations, 
including but not limited to the transmission of data to 
the outside world, be restricted to individuals who pos- 
sess special privileges. Examples of such operations 
are messages (electronic mail) which are directive in 



nature, such as users to transfer funds, and operations 
such as the adding of new orders or the granting of lim- 
ited access to departmental data to users on the Wide 
Area Network 16 (remote login and file transfer). 

5 

Threats Against Department Computing Environ- 
ment 

The threats against the departmental computing 

w environment are shown in Figure 2. 

The data in this environment is vulnerable to theft 
and tampering. Removable media can be stolen, cop- 
ied, and returned with no sign that loss has occurred. 
The fruits of thousands of hours of labor can be stolen 

is in a package that fits easily in a coat pocket. Crucial 
data can be modified or destroyed, either directly or 
through the agency of technical entities such as 
"viruses", which are introduced into the Workstations 10 
and servers through the agency of corrupted media or 

20 through the wide area network connection. 

There are also threats to the privileged operations. 
Unauthorized individuals, masquerading as someone 
else, can cause disruptive or erroneous directives to be 
issued and thereby perpetrate sabotage and fraud . 

25 Malicious "hackers" with access to the wide area net- 
work can use that network to "reach in" to the depart- 
mental computing environment and masquerade as 
authorized users or otherwise obtain access to data, 
which they can then transfer worldwide, again with no 

30 sign that compromise has occurred. 

Accordingly, there is a need for techniques whereby 
a departmental computing system 1 can be converted 
into a "data enclave." Within such an enclave: 

35 (1) Data can be restricted to a single organization, 
such as a government agency or a corporation. 

(2) Sharing of data between organizational ele- 
ments (directorates, departments, projects, etc.) 
can be controlled. For example, it may be required 

40 that data such as a telephone directory be accessi- 
ble by every employee, but data such as engineer- 
ing drawings should not be allowed to circulate 
throughout the whole corporation. 

(3) Sharing of data between individuals in organiza- 
45 tional elements can be controlled. For example, 

even though an individual is a member of the engi- 
neering department, that individual may not have a 
"need to know" for all of the drawings in the depart- 
ment. 

so (4) Data is protected from technical attacks such as 
"viruses" and "worms." 

(5) Intellectual property is protected irrespective of 
whether it is on electronic media, being processed 
in a Workstation, or being transferred around the 

55 local area network. 

(6) The protections are achieved with minimum cost 
and disruption of operations, such as would occur if 
access to the wide area network were forbidden. 
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(7) Privileged operations are restricted to those 
users possessing the requisite privileges and can- 
not be invoked, through masquerading or other 
technical means, by unauthorized users. 

As shown in overview form in Figure 3, and as will 
be described more fully in the Detailed Description of 
the Invention, the facilities provided by the present 
invention convert a departmental computing environ- 
ment into a "data enclave" 20 with a well-defined perim- 
eter 22. Sharing of data within the Enclave 20 is 
controlled, and movement of data within and outside the 
enclave can only be effected by authorized individuals 
with suitable privilege. There are no "sneak paths" or 
"holes" that exist. 

The present invention also minimizes the damage 
that can be done by privileged individuals who become 
subverted. Cryptographic keys are transmitted and 
stored entirely in enciphered form, and well-known tech- 
niques (called "antitamper" technology) can be used to 
protect an enclave key when it is in use inside a crypto- 
graphic device. Theft of elements of the present inven- 
tion does not compromise any part of the operation of 
the invention. 

Individuals desiring access to Media 2,4 have to 
deal with a Secure Computer 24, in this case a security 
server, only when Media 2,4 is initialized. "Unlocking" a 
unit of Media 2,4 requires an operation no more compli- 
cated than using a television remote control. Overhead 
and delay is concentrated at the time a Media 2,4 is 
"unlocked", and no delays or incompatibilities are intro- 
duced during operations using the Media 2 or 4. 

Remotely invoked privileged operations at the 
security server 24 are under the positive control of the 
user. That control is cryptographically protected and 
mutually authenticated. 

Identification and authentication of users to the 
security server 24 is both simpler and more robust than 
former implementations such as passwords. The same 
basic steps are used for security operations dealing with 
Media 2,4 and dealing with the security server 24. 

In the data protection area, the system associates 
Media 2 or 4 primarily with users and secondarily with 
machines or Workstations 10. This is a more natural 
structure than one where media is only useable on a 
single machine or Workstation 10. 

Control logic computes allowed access at the last 
possible moment using the combination of an "access 
vector" assigned to an individual and the "device 
attributes" assigned to a particular Workstation 10, 
which can be used to enforce a variety of security poli- 
cies. For example, an individual's access to data may be 
restricted not only on the basis of the individual's 
attributes but also to protected physical locations. Thus 
an individual's access vector may grant "read" access to 
a unit of media which contains proprietary engineering 
data, but the comparison against the device attributes 
making the access, may restrict display of the contents 
of the unit of media to those machines inside a particu- 



lar facility or office. Physical security measures can then 
be used to restrict who may be in the vicinity when the 
data is displayed. Previous implementations in this area 
have permitted only an "all or nothing" approach to 
5 access. 

Trusted Path 

The problems addressed by the Trusted Path func- 
w tions arise because of the use of networks 1 2 and Work- 
stations 10 to communicate between human users and 
secure computers 24. Malicious hardware and/or soft- 
ware in the Workstation 10 or network, possibly operat- 
ing in concert with a subverted user, has the ability to 
is perform the following hostile actions, 

(1) Masquerade as a secure computer . In this 
attack, a bogus secure computer (not shown) is 
installed on the Network 1 2 and logically interposed 
between the legitimate Secure Computer 24 and 
the human user. The bogus secure computer then 
makes requests of the human user, displays forged 
or modified data, or otherwise induces the user to 
perform some insecure act. For example, the bogus 
secure computer may intercept and discard a mes- 
sage giving a critical order, while all the time pre- 
senting displays to the human user which indicate 
that the message was sent. 

(2) Masquerade as a user site . This is the symmet- 
ric attack to that described in the previous para- 
graph. A bogus user site (not shown) is interposed 
between the legitimate human user and the Secure 
Computer 24. This bogus user site then accesses 
data, or performs operations, which are in violation 
of the security policy. The location of the bogus user 
site enables it to intercept responses from the 
Secure Computer 24, so that the legitimate user is 
unaware that a bogus site is on the network. The 
bulk of the so-called "hacker" attacks that appear in 
the popular press are of this class. 

(3) Masquerade as another user. In this attack, a 
subverted or malicious individual gains access to a 
legitimate site, but then is able to masquerade as a 
different, and in general more privileged, human 
user. The majority of the so-called "insider" attacks 
are of this form. 

(4) Surreptitiously transform data . This is a sophis- 
ticated and extremely dangerous form of attack in 
which some intermediate element in the path 
between the human user 5 and the secure compu- 
ter performs "two-faced" actions. That is, the ele- 
ment displays one set of data to the human user 5 
while simultaneously transmitting something else to 
the Secure Computer 24. For example, malicious 
software in a Workstation may be programmed to 
detect a funds transfer order, and then modify the 
amount or the recipient in ways not intended for use 
by the human user 5. 
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(5) Misdirect or appropriate cryptographic keys . In 
this attack, some intermediate element diverts, cop- 
ies, or otherwise appropriates cryptographic keys 
destined to some authorized user 5 and methods 
and redirects them to unauthorized persons who 
have obtained cryptographic devices and wish to 
use them to either decrypt intercepted data or pre- 
pare and encipher forgeries of data to be submitted 
to the secure computer. 

The Trusted Path, according to the present inven- 
tion, is used for security-relevant interactions between a 
human user and a Secure Computer 24. These interac- 
tions fall into four broad categories, as set forth below. 

(1) Identification and Authentication . In these oper- 
ations, the human user is identifying himself or her- 
self to the Secure Computer 24 for purposes of 
secure processing. There are two aspects to identi- 
fication and authentication: authenticating the iden- 
tity of the human user and authenticating the 
location (e.g. a Workstation 10) from which the 
human user is accessing the Secure Computer 24. 
Both aspects are used by the Secure Computer 24 
to determine the nature of information it will display 
to. or the kinds of actions it will permit to be initiated 
by, the human user. The use of both aspects ena- 
bles the implementation of sophisticated security 
policies by the Secure Computer 24. For example, 
an individual may be authorized to access engi- 
neering drawings, but only from terminals located 
inside the engineering area; even though the indi- 
vidual is authorized for information, the policy may 
prohibit the individual from exercising the authoriza- 
tion when in a residence or temporary lodgings. 

(2) Trusted Command Initiation . These are opera- 
tions performed by the human user which have seri- 
ous security consequences; they will, in general, 
involve the exercise of some special privilege by the 
user. An example of trusted command initiation is 
the decision to override the security policy enforced 
by the secure computer and release data to per- 
sons who would normally be unauthorized to 
access it. Such a facility is necessary to prevent the 
security policy from interfering with proper opera- 
tion in exceptional or emergency situations. 
Another example is the exercise of a human user of 
the privilege to send an official, cryptographically 
authenticated message which has the effect of an 
order or directive. 

(3) Trusted Review . These are operations in which 
the human user wishes to be assure that some ele- 
ment of data contained in the Secure Computer 24 
is exactly as the user intended. For example, a 
human user may wish to perform a trusted review of 
the aforementioned directive prior to performing the 
trusted command which adds an authenticator to 
the message and releases it as "signed 0 by that 
user. 



(4) Key Management . In these operations, the user 
is obtaining cryptographic keys from some central 
key distribution center and loading them in to local 
cryptographic devices 26 at the user's Workstation 

5 10. 

The protocols of the Trusted Path are arranged so 
that all security alarms are raised at specified secure 
computers 24, and there is no user responsibility for 

io responding to an alarm. This feature is an improvement 
over traditional cryptographic checksum and other 
means which display alarms to users and require them 
to notify the proper authorities, since it permits the 
present invention to provide security for users 5 who 

75 may be in physical locations where such notification is 
not possible. 

The protocols in the Trusted Path operate at Layers 
5, 6, and 7 of the ISO standard for communications pro- 
tocols. This means that they are independent of the 

20 nature or topology of the network. All prior means for 
achieving Trusted Path have depended somewhat on 
the nature or topology of the network. 

The elements of the present invention are either 
free-standing units, parts of an already distinguished 

25 Secure Computer 24, or devices which attach to exist- 
ing interfaces to commercial Workstations 10. The only 
modification required to a commercial Workstation 10 is 
a software modification. No security reliance is placed 
on this modification, so that it can be rapidly and eco- 

30 nomically made to the software of a wide variety of com- 
mercial units. 

The present invention uses a small number of spe- 
cial elements in a wide variety of ways. Maximum use is 
made of the cryptographic devices, which are typically 

35 the most expensive parts of a data security device. The 
same devices are used for media protection and 
authenticated interactions with the Secure Computer 
24. Moreover, the elements of the invention are such 
that they can be constructed from readily available com- 

40 mercial technology. 

Summary of the Invention 

The present invention provides a data enclave for 
45 securing data carried on physical units of fixed and 
removable media in a network including a server and 
one or more workstations, with one or more of the work- 
stations including the physical units of fixed media. Pro- 
tected storage is provided in the server and in each of 
so the workstations, which also each include a crypto 
media controller in each workstation that can be used to 
read the fixed media and the removable media. 

A personal keying device is assigned to each user 
in the enclave, and an enclave key is held in the pro- 
55 tected storage in the server and in each of the worksta- 
tions, and used to protect other keys stored or 
transmitted on the network. Each user is provided a per- 
sonal identification number (PIN). A user unique identi- 
fier (user UID) is assigned to each user in the enclave 
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and is stored in the user's personal keying device 
encrypted with the enclave key. User attributes are 
associated with each user to which a user UID has been 
assigned, and used to represent the privileges and 
other security related information that pertains to that s 
user. 

A media key is provided for each unit of media, and 
used to encrypt and protect data carried on the media, 
with the media keys stored in the personal keying 
devices. A media unique identifier (media UID) is pro- w 
vided for each unit of media, stored on the media, and 
used to identify the corresponding media key for the unit 
of media stored in a personal keying device, and to 
identify media attributes assigned to the unit of media. 
Media attributes are associated with each unit of media is 
to which a media UID has been assigned, and used to 
represent the sensitivity or other security related infor- 
mation that may pertain to the data carried on that unit 
of media. 

An access vector is associated with each media key 20 
to form media key/access vector pairs, stored in the per- 
sonal keying devices, and used to represent the possi- 
ble conditions of access to the data encrypted on the 
media for the user assigned to the personal keying 
device holding the media key/access vector pair or pairs 25 
with each access vector formed using the correspond- 
ing media attributes and user attributes, and a set of 
access rules. The media key/access vector pairs are 
stored in the personal keying devices enciphered with a 
combined key including the user's UID, the user's PIN 30 
and the enclave key. Device attributes are assigned to 
each workstation, stored in that device's crypto media 
controller, and used to represent the security attributes 
of the workstations. 

Each crypto media controller includes access con- 35 
trol logic for restricting access to the data on the media 
based on the user's PIN, the access vector and the 
device attributes for the workstation from which access 
is attempted. 

According to another aspect of the invention, there 40 
is provided a Trusted Path for communication between a 
workstation and a secure computer over a urrtrusted 
communication medium, the Trusted Path comprising a 
logic and control unit in the workstation and in the 
secure computer, and an end-to-end authentication 45 
token exchange protocol used to assure the logic and 
control unit in the workstation is communicating with an 
authentic logic and control unit in the secure computer, 
and vice versa. The token exchange protocol operating 
by chaining transactions together so that a forged trans- so 
action entered into the interaction between workstation 
and secure computer is detected the very next time a 
legitimate transaction is received by a logic and control 
unit. The system further including a cryptographic 
checksum protocol used to assure transactions 55 
between the logic and control units have not been tam- 
pered with, the checksum protocol authenticating single 
transactions between the workstation and the secure 
computer rather than sequences of transactions. The 



system also including an identification and authentica- 
tion protocol invoked when a user wishes to interact with 
the secure computer for some period of time, using the 
keyboard and display of the workstation and the 
urrtrusted communications medium, the period of inter- 
action being a session, and the act of initiating a session 
called logon, and that of terminating one is called log- 
out. 

Brief Description of the Drawings 

The operational enhancements and features of the 
present invention become more apparent from a con- 
sideration of the drawings and following detailed 
description. 

Figure 1 is a diagram illustrating a typical depart- 
mental computing environment incorporating a local 
area network with a wide area network. 

Figure 2 is a diagram illustrating possible threats 
against the departmental computing environment. 

Figure 3 is an overall simplified block diagram of a 
secure data processing system illustrating the Data 
Enclave implementation. 

Figure 4 is a simplified block diagram of the main 
data processing elements in the apparatus implement- 
ing the present invention. 

Figure 5 is a simplified block diagram of the Work- 
station data processing elements using a Workstation 
configuration supporting coprocessor cryptography. 

Figure 6 is a simplified block diagram of the Work- 
station data processing elements using a Workstation 
configuration supporting inline cryptography. 

Figure 6a is a pictorial diagram of a personal keying 
device illustrating the appearance, features, and func- 
tions. 

Figure 6b is a schematic diagram of the data ele- 
ments created and utilized for the protection of data in 
the present invention. 

Figure 7 is a simplified block diagram illustrating the 
steps for the extraction of user data at the Workstation, 
implemented in the Media Initialization and Key Gener- 
ation phase of Data Enclave operation. 

Figure 8 is a simplified block diagram illustrating the 
step for preparation and sending of a "Request Packet", 
implemented in the Media Initialization and Key Gener- 
ation phase of Data Enclave operation. 

Figure 9 is a simplified block diagram illustrating the 
step for receipt of a "Request Packet" at the Security 
Server, implemented in the Media Initialization and Key 
Generation phase of Data Enclave operation. 

Figure 10 is a simplified block diagram illustrating 
the steps for the checking of user identity and the gen- 
eration of a Media UID, implemented in the Media Initial- 
ization and Key Generation phase of Data Enclave 
operation. 

Figure 1 1 is a simplified block diagram illustrating 
the steps for Access Vector generation, implemented in 
the Media Initialization and Key Generation phase of 
Data Enclave operation. 
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Figure 12 is a simplified block diagram illustrating 
the steps for "Key Packet" generation and storage, 
implemented in the Media Initialization and Key Gener- . 
ation phase of Data Enclave operation. 

Figure 13 is a simplified block diagram illustrating 5 
the steps for Media UID and "Key Packet" assignment, 
implemented in the Media Initialization and Key Gener- 
ation phase of Data Enclave operation. 

Figure 14 is a simplified block diagram illustrating 
the steps for extracting identification data and forming a 10 
Request, implemented in the Key Assignment phase of 
Data Enclave operation. 

Figure 1 5 is a simplified block diagram illustrating 
the step for the encryption and transmission of a 
"Request Packet", implemented in the Key Assignment is 
phase of Data Enclave operation. 

Figure 16 is a simplified block diagram illustrating 
the steps for the computation of an Access Vector, 
implemented in the Key Assignment phase of Data 
Enclave operation. 2 o 

Figure 17 is a simplified block diagram illustrating 
the steps for key generation, storage, and transmission, 
implemented in the Key Assignment phase of Data 
Enclave operation. 

Figure 18 is a simplified block diagram illustrating 25 
the step for the transfer of the key to the personal keying 
device, implemented in the Key Assignment phase of 
Data Enclave operation. 

Figure 19 is a simplified block diagram illustrating 
the steps for Media Key and Access Vector extraction, 30 
implemented in the Keying of Devices phase of Data 
Enclave operation. 

Figure 20 is a simplified block diagram illustrating 
the steps for Media Key and Access Vector use, imple- 
mented in the Keying of Devices phase of Data Enclave 35 
operation. 

Figure 21 is a simplified block diagram illustrating 
the steps for the initialization of the authentication proc- 
ess, implemented in the Identification and Authentica- 
tion phase of Trusted Path operation. 40 

Figure 22 is a simplified block diagram illustrating 
the step for the authentication of identity and the estab- 
lishment of privileges, implemented in the Identification 
and Authentication phase of Trusted Path operation. 

Figure 23 is a simplified block diagram illustrating 45 
the step for the preparation and transmission of the 
"Response Packet", implemented in the Identification 
and Authentication phase of Trusted Path operation. 

Figure 24 is a simplified block diagram illustrating 
the step for the completion of the authentication so 
sequence, implemented in the Identification and 
Authentication phase of Trusted Path operation. 

Figure 25 is a simplified block diagram illustrating 
the steps for the initiation of a privileged operation, 
implemented in the Privileged Services phase of ss 
Trusted Path operation. 

Figure 26 is a simplified block diagram illustrating 
the steps for the determination of privileges, imple- 



mented in the Privileged Services phase of Trusted 
Path operation. 

Figure 27 is a simplified block diagram illustrating 
the step for the acknowledgment of privileges, imple- 
mented in the Privileged Services phase of Trusted 
Path operation. 

Figure 28 is a simplified block diagram illustrating 
the step for the display of the acknowledgment, imple- 
mented in the Privileged Services phase of Trusted 
Path operation. 

Figure 29 is a block diagram of a secure data 
processing system illustrating the Trusted Path imple- 
mentation. 

Figure 30 is a simplified block diagram showing the 
elements of the Trusted Path when Workstation Unit 
102 is used only for authenticated communications 
between Workstation 131 and Secure Computer 104. 

Figure 31 is a simplified block diagram showing the 
elements of the Trusted Path when Workstation Unit 
102 is used for protection of critical and sensitive data at 
Workstation 131 as well as authenticated communica- 
tions between Workstation 131 and Secure Computer 
104. 

Figure 32 is a simplified block diagram illustrating 
the internal logic of Cryptographic Units 112 and 142. 

Figure 33 is a flow diagram detailing the steps used 
by the Authentication Token Exchange Protocol to 
"chain" together transactions of other protocols in 
Trusted Path operation. 

Figure 34 is a pictorial diagram displaying the loca- 
tions of the user-visible elements of the Trusted Review 
Protocol used in Trusted Path operation. 

Figure 35 shows an alternate embodiment of the 
Data Enclave system. 

Figure 36 shows the configuration for initializing 
fixed media according to the alternate embodiment of 
Figure 35. 

Figure 37 shows the configuration for initializing 
removable media according to the alternate embodi- 
ment of Figure 35. 

Detailed Description of the Invention 

In the following detailed description of the preferred 
embodiments, reference is made to the accompanying 
drawings which form a part hereof, and in which is 
shown by way of illustration, specific embodiments in 
which the invention may be practiced. It is to be under- 
stood that other embodiments may be utilized and 
structural changes may be made without departing from 
the scope of the present invention. 

The term "logic" is used throughout the ensuing 
description with reference to the structure of various 
electronic components of the invention. The term is 
intended to have a broad meaning, and to encompass 
hardware implemenations, software implementations, 
and combinations thereof. 
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Processing Elements 

The present invention consists of processing ele- 
ments and data elements. The interrelation of the 
processing elements is shown generally in Figures 3 s 
and 4 (in part described above) and in more detail in 
Figures 5 and 6. The descriptions given below show 
cryptographic protection provided only to those distin- 
guished transmissions required in the operation of the 
invention. In such a case, the elements of the invention to 
are preferably arranged with regard to the Workstation 
10 as shown in Figure 5. 

If it is desired to protect all transmissions over the 
Local Area Network 12, e.g., to prevent wiretapping or 
other monitoring by unauthorized personnel, then the 75 
Crypto Media Controller 26 could be used to encipher 
and decipher all data going out over the Network 12. In 
this case, the elements of the invention could be 
arranged with regard to the Workstation 10 as shown in 
Figure 6. 20 

Security Server 

The Security Server 24, a secure computer, is a 
distinguished server that performs gateway and security 25 
functions at the interface between the Local Area Net- 
work 1 2 and the Wide Area Network 16. It also performs 
the key management and backup functions for the cryp- 
tography in the Enclave 20. The Security Server 24 can 
be implemented in the form of a secure computer for 30 
example, as disclosed in U.S. Patent No. '4,621, 321 to 
Boebert et al, entitled "Secure Data Processing System 
Architecture", 4,713,753 to Boebert et al, entitled 
"Secure Data Processing System Architecture with For- 
mat Control", and 4,701 ,840 to Boebert et al, entitled 35 
"Secure Data Processing System Architecture". 

Personal Keying Device 

Each user 5 is issued a Personal Keying Device 30. 40 
Personal Keying Devices 30 are used for key insertion 
and individual authentication. A Personal Keying Device 
30 (shown in more detail in Figure 6a) preferably con- 
tains fixed or removable electronic storage and proces- 
sor 32, a keypad 34, a display 36, and a data transfer 45 
interface 38 that can be either wired or wireless (e.g., 
radio, infrared) and is compatible with an interface 31 on 
a Crypto Media Controller 26. The Personal Keying 
Device 30 can be highly portable, e.g., pocket calculator 
size. Personal Keying Devices 30 may also be equipped so 
with theft detection circuitry to prevent them from being 
physically removed from the enclave working area. 

Crypto Media Controller 

55 

The standard media controller on each Workstation 
1 0 is replaced with a Crypto Media Controller 26. Crypto 
Media Controllers 26 perform key management, media 
encryption and decryption, and authentication func- 



tions. A Crypto Media Controller 26 has the same inter- 
faces as the standard media controllers, as well as a 
data transfer interface that is compatible with the one on 
the Personal Keying Device 30. The Crypto Media Con- 
trollers 26 can be the same size as the standard media 
controllers they replace. 

Data Elements 

The present invention also includes a variety of 
data elements, as described below and schematically 
represented in Figure 6b. 

Enclave Key 

There is one Enclave Key 40 per organization. It is 
held in protected storage in the Security Server 24 and 
the Crypto Media Controllers 26, and is used to protect 
Media Keys 42 when they are being transmitted along 
the LAN 12. 

Media Key 

There is one Media Key 42 assigned to each phys- 
ical unit of the media, whether that unit is fixed 2 or 
removable 4. Assignment is done when the media is ini- 
tialized at the Workstation 1 0. This key is used to protect 
the data on the Media 2 or 4. 

Combined Keys 

Combined Keys 44 are generated in the operation 
of the present invention from other data elements and 
keys. 

Media Unique Identifier (Media UID) 

Each physical unit of media, whether fixed 2 or 
removable 4, is assigned a Media Unique identifier 46 
(Media UID). This number is generated by the Security 
Server 24, and stored in whatever field the Media 2 or 4 
software uses to identify physical units (e.g., Volume 
Label). The Media UID 46 is used to find the appropriate 
Media Key 42 in the Personal Keying Device 30, and to 
locate that data pertaining to the unit of media which is 
stored in the Security Server 24 (e.g., Media Attributes). 

User Unique Identifier (User UID) 

Each individual who has potential access to 
encrypted media is assigned a User Unique Identifier 
48 (User UID) which is stored in that user's Personal 
Keying Device 30, encrypted with the Enclave Key 40. 
The User UID 48 forms part of the key used to protect 
Media Keys 42 in the Personal Keying Device 30, and is 
used to extract that data pertaining to the user 5 which 
is stored in the Security Server 24 (e.g., User 
Attributes). 
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Personal Identification Number (PIN) 

Each user 5 is assigned a Personal Identification 
Number 50 (PIN), which is used to form part of the key 
that protects Media Keys 42 in the Personal Keying 
Device 30. 

Access Vector 

An Access Vector 52 is associated with each Media 
Key 42 stored in a Personal Keying Device 30. The 
Access Vector 52 is used to represent those possible 
conditions of access to the data enciphered with that 
Media Key 42 that may apply to the individual assigned 
to that Personal Keying Device 30. 

Media Attributes 

Media Attributes 54 are associated with each ele- 
ment of Media 2 or 4 to which a Media UID 46 has been 
assigned. Media Attributes 54 are used to represent the 
sensitivity or other security related information that may 
pertain to the data on that element of media. 

User Attributes 

A set of "User Attributes'' 56 are associated with 
each user to which a User UID 48 has been assigned 
User Attributes 56 are used to represent the privileges 
and other security related information which pertains to 
that user. 

Device Attributes 

Device Attributes 58 are assigned to each Crypto 
Media Controller 26, and reflects the Security Attributes 
57 of the machine in which the Crypto Media Controller 
26 is installed. Device Attributes 58 are combined with 
Access Vectors 52 to set limits on media access (e.g., 
read only). Device Attributes 58 are typically defined by 
the physical security measures which surround the 
Workstation 10 in which the Crypto Media Controller 26 
is installed. For example, a Workstation 10 installed in 
an open environment may have Device Attributes 58 set 
to "Authorized to Process Public Data Only", whereas 
one in a closed engineering facility may have Device 
Attributes 58 set to "Authorized to Process Proprietary 
Engineering Data." 

Requests 

Requests 60 are transmitted back and forth 
between the Crypto Media Controller 26 and Security 
Server 24 in the course of operations which require 
cooperation between the two devices. Requests 60 con- 
tain a variety of information depending on the nature of 
the operation being performed as well as optional integ- 
rity fields such as cyclic redundancy checks or check 
sums. 



Countersigns 

The purpose of the Countersign 62 logic is to pre- 
vent malicious code in the Workstations 10 from mas- 

5 querading as the Security Server 24, and thereby 
duping users 5 into taking inappropriate actions. Each 
time a user 5 is identified to the Security Server 24 (e.g., 
each new session), the Security Server 24 generates a 
"fresh" Countersign 62. Countersigns 62 are words, 

10 symbols, or phrases which are easy to remember and 
which are generated by some process which makes it 
computationally infeasible to guess from one Counter- 
sign 62 what the value of the next one will be. The 
Countersign 62 for a session is presented by the Secu- 

75 rity Server 24 as a header to each message it sends to 
the user 5 when communicating over a Trusted Path. 
The present invention also provides a Trusted Path." A 
Trusted Path is a logical communications path between 
a human user 5 and the Secure Computer 24 (Figure 3). 

20 A Trusted Path differs from other modes of communica- 
tion in that there is a high degree of assurance on the 
part of both parties that the communication is authentic; 
that is, the human user is truly seeing what the secure 
computer intends the human user to see, and the 

25 secure computer is making decisions on the basis of 
precisely what the human user has transmitted to it. 

The Countersign 62 is displayed to the user 5 on 
the Personal Keying Device 30 when the Trusted Path is 
in effect, and is protected from the Workstations 10 and 

30 the communications media by cryptography and is com- 
putationally infeasible to guess. It's presence on the dis- 
play of the Personal Keying Device 30 is a positive 
indication to a user that the communication in which the 
user is engaged, is taking place over a Trusted Path to 

35 the Security Server 24. 

Countersigns 62 are arranged so that the logic in 
the Security Server 24 can, for any given Countersign 
62, determine what the previous Countersign 62 in the 
sequence was. That is, given a Countersign 62, the 

40 Security Server 24 can compute or retrieve a correct 
value of the previous one, which is called the "last coun- 
tersign" 62'. 

OPERATION OF DATA ENCLAVE 20 

45 

The present invention makes use of cryptography 
to protect the data on Media 2 or 4 and uses an innova- 
tive method to distribute and protect the cryptographic 
keys in order to achieve security, flexibility, and ease of 

so use. The same cryptographic services are used to pre- 
vent unauthorized access through the Wide Area Net- 
work 16, or the unauthorized use of privileged services. 

As described in more detail below, protection of the 
data on Media 2 or 4 takes place in three broad phases. 

55 The first phase, which is done very infrequently, is 
media initialization and key assignment to the individual 
user 5 requesting the initialization. The second phase, 
which is also infrequently done, is the assignment of a 
key for already-initialized Media 2 or 4 to additional indi- 
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viduals. The third phase, which is done more frequently, 
is the keying of devices, so access to the data may be 
made. 

Media Initialization and Key Generation 5 

The media initialization and key generation phase 
generates a Media Key 42 and an Access Vector 52 for 
a unit of Media 2 or 4 and places them in enciphered 
form in the Personal Keying Device 30 assigned to the w 
individual requesting the initialization. This data is also 
archived in the Security Server 24 so that it may be 
restored at a later time. 

Key Assignment 15 

The key assignment phase assigns a Media 
Key/Access Vector pair, or combination, for an already- 
initialized unit of media to a new individual. The Media 
Key 42 will be a copy of the one generated when the unit 20 
of Media 2 or 4 was initialized. The Access Vector 52, 
since it depends on User Attributes 56 as well as Media 
Attributes 54, will be newly computed. 

Keying of Devices 25 

The keying of devices phase automatically extracts 
the proper Media Key/Access Vector combination from 
the Personal Keying Device 30, decrypts them and uses 
them to allow controlled access to the unit of Media 2 or 30 
4. The Media Key/ Access Vector combination are enci- 
phered with a Combined Key 44 which includes the 
users PIN 50. This restricts a particular Media 
Key/Access Vector combination to the individual to 
whom it was assigned. 35 

Media Initialization and Key Generation 

The operations in the Media Initialization and Key 
Generation Phase occur when a blank unit of Media 2 or 40 
4 is to be prepared for safe use in the Enclave 20. This 
preparation involves initializing the Media 2 or 4, assign- 
ing a Media UID 46 to it, generating a Media Key 42 
which is unique to that unit of media, and assigning a 
Media Key/Access Vector pair to the user 5, initializing 45 
the media. 

The operations in this phase are keyed to the dia- 
grams in Figure 7 through Figure 13. The logic used to 
implement the Trusted Path facilities is omitted from 
these diagrams. so 

Siep_l (Figure 7) 

An individual brings together a blank unit of 
physical Media 2 or 4 and his or her Personal Key- 
ing Device 30 to a Workstation 10 which is 55 
equipped with a Crypto Media Controller 26 and 
attached to a Local Area Network 12. If the Media 4 
is removable, this is done by carrying Media 4 and 
Personal Keying Device 30 to an appropriate Work- 



station 10. If Media 4 is permanently installed 
(Fixed Media 2), Personal Keying Device 30 is 
brought to the Workstation containing the fixed 
media controlled by Crypto Media Controller 25, 
and the Workstation 10 is temporarily attached to 
the Local Area Network 12. 
Step 2 (Figure 7) 

The individual user 5 desiring access to Media 
2 or 4 then enters his or her PIN 50 into Personal 
Keying Device 30 which transmits it to Crypto 
Media Controller 26, where it is stored for use in 
later steps. 
Step 3 (Figure 7) 

Crypto Media Controller 26 then extracts the 
encrypted User UID 48* from their Personal Keying 
Device 30, decrypts the User UID 48 using the 
Enclave Key 40, and stores it for use in later steps. 
Step 4 (Figure 8) 

Crypto Media Controller 26 forms a packet con- 
sisting of the PIN 50, the User UID 48. and a 
Request 60 for media initialization. The request 
field will include the nature of the request and 
appropriate supporting data such as the Security 
Attributes 57 to be assigned to Media 2 or 4. Key 
Management Crypto 70 in Crypto Media Controller 
26 enciphers it using the Enclave Key 40, and trans- 
mits it across the Local Area Network 12 to Security 
Server 24. 
SteoS (Figure 9) 

Security Server 24 receives the encrypted 
packet 90, decrypts it using its copy of the Enclave 
Key 40, and stores the PIN 50, User UID 40, and 
Request 60 for use in later steps. 
(Figure 10) 

Storage Search Logic 72 in Security Server 24 
uses the User UID 48 to index User Attribute Data 
Base 80, which returns a pass value if the PIN 50 
entered by the user 5 in Step 1 is the same as that 
stored in the data base, i.e., a valid PIN 50. User 
Attribute Data Base 80 returns a fail value if the PIN 
50 entered by the user is invalid. A fail value will 
cause the initialization process to abort and a noti- 
fication to be sent back to Crypto Media Controller 
26, which will display it to the user 5 in an appropri- 
ate fashion. The abort sequence is not diagrammed 
in the figures. 
Si£&7 (Figure 10) 

Storage Search Logic 72 extracts the Media 
Attributes 54 from the Request and commands 
Media Attribute Data Base 82 to make an entry for 
the new element of Media 2 or 4. Since Media 
Attribute Data Base 82 is indexed by the Media UID 
46, this has the effect of creating a new Media UID 
46 which is sent to Crypto Media Controller 26 and 
saved for use in later steps. 
Step 8 (Raure 111 

Storage Search Logic 72 uses the User UID 48 
to index User Attribute Data Base 80 and extract 
the set of Security Attributes 57 pertaining to this 
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user, and passes these attributes to Security Policy 
Logic 86. 

SteeJ (Figure 11) 

Security Policy Logic 86 accepts the Media 
Attributes 54 and User Attributes 56, and, using a 5 
set of rules defined by the administrators of the 
facility, computes an Access Vector 52 which 
defines limits on the access this user 5 may have to 
this unit of Media 2 or 4. This computation may 
involve the intervention of administrative personnel 10 
to authorize or deny the granting of certain privi- 
leges, 

SteeJO (Figure 12) 

Key Management Crypto 70, with the optional 
aid of authorized individuals, then generates a is 
Media Key 42 for this unit of Media 2 or 4. The man- 
ner of generation can involve computation, access 
to stored tables, requests for inputs from authorized 
individuals, or any combination thereof. Other 
methods of key generation may also be used. The 20 
Media Key 42 and Access Vector 52 pair 91 are 
enciphered with a combined key 44 consisting of 
the User UID 48, the user's PIN 50 and the Enclave 
Key 40. 

SteejM (Figure 12) 25 

The enciphered packet is sent to Storage 
Search Logic 72 where the User UID 48 and Media 
UID 46 are used to store the enciphered packet 92 
in Crypto Key Data Base 84. The Media UID and 
the enciphered packet 92 are transmitted along the 30 
LAN 12 to Crypto Media Controller 26. 
Steej[2 (Figure 13) 

The Media UID 46 arrives at Crypto Media 
Controller 26 and is written to the appropriate loca- 
tion on Media 2 or 4 (e.g., Volume Label). 35 
Ste&J3 (Figure 13) 

The enciphered Media Key/Access Vector pair 
packet 92 arrives at Crypto Media Controller 26 and 
the Media UID 46 is used as an index to store the 
enciphered pair packet 92 in Personal Keying 40 
Device 30. 

At this point the initialization process is com- 
plete. The media can be identified and the individ- 
ual Personal Keying Device 30 contains a Media 
Key 42 which can only be used by someone who 45 
has physical possession of that Personal Keying 
Device 30, knows that individual's PIN 50, and has 
the Media 2 or 4 controlled by a Crypto Media Con- 
troller 26 containing the Enclave Key 40. The indi- 
vidual's Personal Keying Device 30 also contains so 
an Access Vector 52 which defines further restric- 
tions on access in a manner that is specific to the 
individual who has physical possession of that Per- 
sonal Keying Device 30 and knows that individual's 



Key Assignment 

The operations in the Key Assignment Phase of the 
invention occur when an already-initialized unit of Media 
2 or 4 is to be shared with a user 5 other than the one 
who initialized it. In this case, the unit of Media 2 or 4 
has a Media Key 42 generated for it, and a Media 
Key/Access Vector pair 91 has been assigned to the ini- 
tial user of the unit Media 2 or 4. The necessary steps 
are to copy the Media Key/Access Vector pair 91 to the 
new user 5. 

The operations in this description are keyed to the 
diagrams in Figure 14 through Figure 18. The logic used 
to implement the Trusted Path facilities is omitted from 
these diagrams. 

SteeJ. (Figure 14) 

An individual brings together a unit of physical 
Media 2 or 4 and his or her Personal Keying Device 
30 to a Workstation 10 which is equipped with 
Crypto Media Controller 26, and which is attached 
to the Local Area Network 12. If Media 2 or 4 is 
removable, this is done by carrying Media 4 and 
their Personal Keying Device 30 to an appropriate 
Workstation 10. If Media 2 or 4 is permanently 
installed (fixed media). Personal Keying Device 30 
is brought to the computer containing the fixed 
Media 2 controlled by Crypto Media Controller 26. 
Stee_2 (Figure 14) 

The individual desiring access to Media 2 or 4 
then enters his or her PIN 50 into Personal Keying 
Device 30 which transmits it to Crypto Media Con- 
troller 26, where it is stored for use in later steps. 
Slfie_3 (Figure 14) 

Crypto Media Controller 26 then extracts the 
encrypted User UID 48 from Personal Keying 
Device 30, decrypts the User UID 48 using the 
Enclave Key 40 and stores it for use in later steps. 
Steg_4 (Figure 14) 

Storage Search Logic 72 in Crypto Media Con- 
troller 26 then reads the Media UID 46 off Media 2 
or 4 and searches Persona! Keying Device 30 for a 
Media Key/Access Vector pair 91 for this unit of 
Media 2 or 4 for this user 5. Finding none, it gener- 
ates a Request 60 for key assignment. 
£i£&5 (Figure 15) 

Key Management Crypto 70 forms a request 
packet 94 consisting of the PIN 50, User UID 48, 
Media UID 46 and Request 60, encrypts it with the 
Enclave Key 40, and transmits it over the Local 
Area Network 12 to Security Server 24. 
Slep_6 (Figure 16) 

Security Server 24 receives the encrypted 
packet 94, decrypts it using its copy of the Enclave 
Key 40, and stores the PIN 50, User UID 48, Media 
UID 46 and Request 60 for use in later steps. 
SteELZ (Figure 16) 

Storage Search Logic 72 in Security Server 24 
uses the User UID 48 to index User Attribute Data 
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Base 80. User Attribute Data Base 80 returns a 
pass value if the PIN 50 entered by the user 5 was 
the same as that stored in the data base (i.e. valid). 
User Attribute Data Base 80 returns a fail value if 
the PIN 50 entered by the user is invalid. A fail value 5 
will cause the assignment process to abort and a 
notification to be sent back to Crypto Media Con- 
troller 26, which will display it to the user in an 
appropriate fashion. The abort sequence is not dia- 
grammed in the figures. 10 
SlegLS (Figure 16) 

The User UID 48 is used as an index into User 
Attribute Data Base 80 by Storage Search Logic 72, 
and the Security Attributes 57 of the user 5 request- 
ing key assignment are extracted and passed to 15 
Security Policy Logic 86. 
Step 9 (Figure 16) 

The Media UID 46 is used as an index into 
Media Attribute Data Base 82 by Storage Search 
Logic 72, and the Security Attributes 57 of the 20 
denoted item of Media 2 or 4 are extracted and 
passed to the Security Policy Logic 86. 
StfiRlO (Figure 16) 

Security Policy Logic 86 accepts these 
Attributes 57, and, using a set of rules defined by 25 
the administrators of the facility, computes an 
Access Vector 52 which defines limits on the 
access this user 5 may have to this unit of Media 2 
or 4. This computation may involve the intervention 
of administrative personnel to authorize the grant- 30 
ing or denying of certain privileges. This Access 
Vector 52 is saved for use in later steps. 
Step 11 (Figure 17) 

The Media UID 46 is used by Storage Search 
Logic 72 to find an enciphered key packet in Crypto 35 
Key Data Base 84 which has been previously 
stored and which contains a Media Key 42 for this 
unit of media Since the Media 2 or 4 has been ini- 
tialized and assigned a Media UID 46, then at least 
one such packet must exist. Any such packet will 40 
suffice, since all packets pertaining to a given unit 
of Media 2 or 4 will contain the same Media Key 42. 
When such a packet is found, the Media Key 42 is 
extracted from it for use in later steps. 
Step 12 (Figure 1 7) 45 

A new Key Packet 93 is formed consisting of 
the Media Key 42, Access Vector 52, User UID 48, 
and Media UID 46 and placed in Crypto Key Data 
Base 84 for archival storage and retrieval. 
Step 1 3 (Figure 17) 50 

The Media Key and Access Vector pair 91 are 
enciphered with a Combined Key 44 consisting of 
the User UID 48, the user's PIN 50, and the Enclave 
Key 40, and the enciphered packet 92 is transmitted 
along the LAN 12 to Crypto Media Controller 26. 55 
Step 14 ( Figure 18) 

The Media UID 46 is used as an index to store 
the enciphered Media Key/ Access Vector pair 91 in 
Personal Keying Device 30. 



At this point the new individual's Personal Keying 
Device 80 contains a Media Key 42 which can only be 
used by someone who has physical possession of that 
Personal Keying Device 30, knows that individual's PIN 
50, and has the Media 2 or 4 controlled by a Crypto 
Media Controller 26 containing the Enclave Key 40. The 
individual's Personal Keying Device 30 also contains an 
Access Vector 52, which defines further restrictions on 
access in a manner that is specific to the individual who 
has physical possession of that Personal Keying Device 
30 and knows that individual's PIN 50. 

Keying of Devices 

The operations in the Keying of Devices Phase 
occur when a Media Key/Access Vector pair 91 for a unit 
of Media 2 or 4 has been assigned to a user 5, and that 
user 5 wants to exercise the assigned accesses. 
The steps in this description are keyed to the diagrams 
in Figures 19 and 20. The logic used to implement the 
Trusted Path facilities is omitted from these diagrams. 

Sle&l (Figure 19) 

An individual user 5 establishes a data transfer 
interface between his or her Personal Keying 
Device 30 and any Crypto Media Controller 26 con- 
taining the Enclave Key 40. and between that 
Crypto Media Controller 26 and Media 2 or 4 the 
individual user 5 desires to access. In the latter 
case, this will involve placing the unit of Media 4 into 
the appropriate device (e.g., diskette drive). 
Stee_2 (Figure 19) 

The individual user 5 desiring access to Media 
2 or 4 then enters his or her PIN 50 into Personal 
Keying Device 30 which transmits it to Crypto 
Media Controller 26, where it is stored for use in 
later steps. 
Step 3 (Figure 19) 

Storage Search Logic 72 in Crypto Media Con- 
troller 26 reads the Media 2 or 4 and extracts the 
Media UID 46. 
Step 4 (Figure 19) 

Using the Media UID 46, Storage Search Logic 
72 searches Storage 78 in Personal Keying Device 
30 and extracts the enciphered Media Key/Access 
Vector pair packet 92 and passes it to Key Manage- 
ment Crypto 70. 
Step 5 (Figure 19) 

The enciphered User UID 48' is fetched from 
Personal Keying Device 30 and deciphered using 
the Enclave Key 40. 
SteRl (Figure 19) 

The User UID 48, PIN 50, and Enclave Key 40 
are then combined to form the Combined Key 44 to 
decrypt the Media Key/ Access Vector packet 92. 
The Media Key 42 is passed to Data Crypto 74, and 
the Access Vector 52 is passed to Access Control 
Logic 76. 

Step 7 (Figure 20) 
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Workstation's 10 internal logic makes a request 
for data. That logic need not be aware the data is 
protected by cryptography. The request illustrated 
in the figure is a "read" request, but the handling of 
"write" requests are symmetric. 5 
Stee_8 (Figure 20) 

Enciphered data 3* is then fetched from Media 
2 or 4. 

Step 9 (Figure 20) 

Data Crypto 74 deciphers the data using the w 
Media Key 42 and passes data 3 to the Access 
Control Logic 76. 
Step 10 (Figure 20) 

Access Control Logic 76 consults the Access 
Vector 52 and the Device Attributes 58 contained 75 
within itself and decides whether the desired mode 
of access ("read," "write," etc.) shall be permitted. If 
not, the data transfer is aborted and an error indica- 
tion is sent to the Workstation 10. 

At this point the data has been transferred to 20 
the Workstation 10 for processing. Removal of the 
Media 2 or 4 or the Personal Keying Device 30 from 
the Crypto Media Controller 26 will cause the com- 
plete reset of the Crypto Media Controller 26 and 
require the keying process be started from the 25 
beginning. 

Trusted Path 

Identification and Authorization 30 

This phase of the operation involves the steps 
whereby a user 5 presents his or her identity to the 
Security Server 24 and has that identity authenticated 
and a set of privileges associated with the user 5 at the 35 
Security Server 24. 

This operation is protected against forged identities 
and authentications, and so-called "replay" attacks in 
which malicious software in other Workstations 10 mas- 
querades as the authentications mechanism, accepts 40 
identification and authorization data (such as pass- 
words) from an unwitting user 5, and then passes that 
data to an unauthorized individual. 

The operation is also protected against compro- 
mise of the authentication data in the Personal Keying 45 
Device 30. The invention uses the Countersign logic to 
effect this protection. It will be recalled that Counter- 
signs 62 come in a sequence which is generated by the 
Security Server 24, but which is computationally infeasi- 
ble for an outsider to guess. Thus, for each Countersign so 
62, the Security Server 24 (but no one else) can deter- 
mine the value of Last Countersign 62'. 

The Last Countersign 62' for a given is stored in a 
distinguished location in that user's Personal Keying 
Device 30. At each identification and authentication ss 
interaction the Last Countersign 62' is extracted from 
the Personal Keying Device 30 and compared with the 
Last Countersign 62' independently generated or 
retrieved by the Security Server 24. If the two values are 



unequal then it is known that the identification and 
authentication process has been compromised and 
suitable alarms are raised. 

The manner in which this mechanism operates can 
be made clear from example. Assume that the 
sequence of Countersigns 62 is "A," "B," "C," etc. Fur- 
ther assume that a given user's Personal Keying Device 
30 contains the Last Countersign 62' value "A". Since it 
is computationally infeasible for an attacker to guess 
this value, the attacker's recourse is to either steal the 
Personal Keying Device 30 or copy the data from it. 

tf the attacker steals the Personal Keying Device 
30, then its absence will be noted and alarms will be 
raised. If the attacker copies the Last Countersign 62' 
and by some subterfuge succeeds in being authenti- 
cated as the legitimate user 5, then the identification 
and authentication process will update the Last Coun- 
tersign 62' value in the spurious Personal Keying Device 
30 to "B." When the legitimate user 5 attempts identifi- 
cation and authentication, the Last Counterside 62' in 
his or her Personal Keying Device 30 will still be at "A"; 
the difference will be noted by the Security Server 24 
and alarms raised. 

Thus, the copying and successful use of data from 
a Personal Keying Device 30 will enable a false identity 
to be presented to the Security Server 24 only until the 
time at which the legitimate user 5 attempts identifica- 
tion and authentication. 

The steps involved in this phase of the operation 
are keyed to the diagrams given in Figure 21 through 
Figure 24. The logic used in data protection is omitted 
from these diagrams. 

Steal (Figure 21) 

The User UID 48, encrypted with the Enclave 
Key (48') is extracted from the user's Personal Key- 
ing Device 30. 
Step_2 (Figure 21) 

The Last Countersign 62* (denoted "Old C/S" in 
Figure 21), encrypted with the Enclave Key 40, is 
extracted from the user's Personal Keying Device 
30. 

Step 3 (Figure 21) 

The user 5 desiring access to operations on the 
Security Server 24 then enters his or her PIN 50 
through the keyboard on the Personal Keying 
Device 30. 
Steal (Figure 21) 

The User UID 48' and Last Countersign 62' are 
decrypted, combined with the PIN 50, and re- 
encrypted with the Enclave Key 40 for transmission 
to the Security Server 24. 
Step 5 (Figure 22) 

The combined Last Countersign 62', PIN 50, 
and User UID 48 are decrypted using the Enclave 
Key 40 and passed to the storage search logic 72. 
That logic searches the User Attributes Data Base 
80 for the authentication record belonging to this 
user 5, compares the User UID/PIN combination 92 
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that was entered against the stored value, and 
checks the Last Countersign 62' from the Personal 
Keying Device 30 against the stored value from the 
previous identification and authentication interac- 
tion. Based on these checks the logic computes a 
Result 94 (e.g., "Login Successful," "Login Failed") 
and in the case of successful identification, a set of 
privileges which that user may exercise in future 
interactions with the Security Server 24. Also in the 
case of successful identification, the next Counter- 
sign 62 in the sequence is generated, stored in the 
User Attribute Data Base 80 as the new Last Coun- 
tersign 62' and saved for use in the next step. This 
value is denoted "New C/S" in the figures. 
Step 6 (Figure 23) 

The Result 94 and the updated Countersign 62 
value is encrypted with the Enclave Key 40 and 
transmitted to the Crypto Media Controller 26. 
Step 7 (Figure 24) 

The combined Result and updated Counter- 
sign 62 is decrypted. The updated Countersign 62 
is encrypted with the Enclave Key 40 and stored in 
the user's Personal Keying Device 30 as the new 
value of Last Countersign 62'. The Countersign and 
result are displayed on the display portion of the 
Personal Keying Device 30. 

At this point, the user has been authenticated 
to the Security Server 24 and assigned a set of 
Privileges 95, which may be invoked at a later time. 
The Security Server 24 has also displayed to the 
user 5 the Countersign 62 that it will use in the ses- 
sion to authenticate itself to the user. 

Privileged Services 

This phase of the operation involves a user 5, 
whose identity has already been presented to and 
authenticated by the Security Server 24, invoking a priv- 
ileged operation by that Server 24. The user is identified 
to the Security Server 24 by the User UID 48. The Secu- 
rity Server 24 is authenticated to the user by the Coun- 
tersign 62. 

The steps involved in this phase of the operation 
are keyed to the diagrams given in Figure 25 to Figure 
28. The logic used in data protection is omitted from 
these diagrams. 

Step 1 (Figure 25) 

The user 5 signals his or her desire to invoke a 
privileged operation by an appropriate entry in the 
keyboard 34 of the Personal Keying Device 30. This 
entry is shown as "ATTN" in the Figures. The User 
UID 48 is then extracted from the Personal Keying 
Device 30. 
Step 2 (Figure 25) 

The combination of the "ATTN" signal and the 
User UID 48 is encrypted with the Enclave Key 40 
and transmitted to the Security Server 24. 
Step 3 (Figure 26) 



The combination of the "ATTN" signal and the 
User UID 48 is decrypted using the Enclave Key 40. 
Step 4 (Figure 26) 

The User UID 48 is transferred to the Storage 
Search Logic 72 and the "ATTN" signal is trans- 
ferred to the Privileged Operation Logic 73. 
Step 5 (Figure 26) 

The Storage Search Logic 72 then extracts the 
user's Privileges 95 from the User Attribute Data 
Base 80 and passes them to the Privileged Opera- 
tion Logic 73. 
Step 6 (Figure 27) 

The Storage Search Logic 72 extracts the 
Countersign 62 from the User Attribute Data Base 
80 and passes it to the Key Management Crypto 
70, which encrypts it with the Enclave Key 40 and 
transmits it to the Crypto Media Controller 26, 
which initiated the request. 
Step 7 (Figure 28) 

The Crypto Media Controller 26 decrypts the 
Countersign 62 and causes it to be displayed on the 
Personal Keying Device 30. 

At this point, both the user and the Security 
Server 24 are aware, in authenticated fashion, that 
a privileged operation is to be invoked. The invoca- 
tion of the operation, which may involve multiple 
interactions, can then proceed. The operation is ter- 
minated by a series of steps which is symmetric to 
those presented above. 

An alternate, preferred embodiment of the 
Trusted Path is described further below, with refer- 
ence to Figures 29 - 34. The Trusted Path phase of 
the Data Enclave process is preferably imple- 
mented using the relevant aspects of this alternate 
embodiment. These aspects include Identification 
and Authentication, Trusted Command Initiation 
(Privileged Services) and Key Management. 

ADVANTAGES OVER PRIOR ART 

The Data Enclave System of the present invention 
provides a number of advantages over the prior art, as 
outlined below. 

Security 

The data enclave invention offers comprehensive 
security to the data within the Enclave 20; there are no 
"sneak paths" or "holes" that exist in approaches where 
the data is protected on media but the Wide Area Net- 
work 16 connections are open, or vice versa. 

The invention minimizes the damage that can be 
done by privileged individuals who become subverted. 
Cryptographic keys are transmitted and stored entirely 
in enciphered form. Well-known techniques (so-called 
"antitamper" technology) can be used to protect the 
Enclave Key when it is stored in the Crypto Media Con- 
trollers 26 and the Security Server 24. Theft of elements 
of the invention such as the Personal Keying Device 30 
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and the Crypto Media Controllers 26 does not compro- 
mise any part of the operation of the invention. 

Low Cost 

The invention uses a small number of special ele- 
ments in a wide variety of ways. Maximum use is made 
of the cryptographic devices, which are typically the 
most expensive parts of a data security device. The 
same devices are used for media protection and 
authenticated interactions with the Security Server. 

Ease of Use 

Individuals desiring access to media have to deal 
with the Security Server only when media is initialized. 
"Unlocking" a unit of media requires an operation no 
more complicated than using a TV remote control. 
Overhead and delay is concentrated at the time a media 
is "unlocked" and no delays or incompatibilities are 
introduced during operations using the media. 

Identification and authentication of users to the 
Security Server 24 is both simpler and more robust than 
prior art such as passwords. The same basic steps are 
used for security operations dealing with media and 
dealing with the Security Server 24. 

Exceptional or emergency situations can be 
accommodated. A trusted command initiation can over- 
ride a security policy enforced by the Security Server 24 
and release data to persons who would normally be 30 
unauthorized to access it. 

Flexible Control of Media 

In the data protection area, the system associates 35 
Media 2 or 4 primarily with users and secondarily with 
machines. This is a more natural structure than one 
where Media 2 or 4 is only useable on a single machine. 

The access control logic, which computes allowed 
access at the last possible moment using the combina- 40 
tion of an individual's Access Vector 52 and the Device 
Attributes 58 assigned to a particular Workstation, can 
be used to enforce a variety of security policies. For 
example, an individual's access to data may be 
restricted not only on the basis of the individual's 45 
attributes, but also to protected physical locations. 
Thus, an individual's Access Vector 52 may grant "read" 
access to a unit of media which contains proprietary 
engineering data, but the comparison against the 
Device Attributes 58 of the Crypto Media Controller 26 so 
making the access may restrict display of the contents 
of the unit of media to those machines inside a particu- 
lar facility or office. Physical security measures can then 
be used to restrict who may be in the vicinity when the 
data is displayed. Prior art in this area permits only an 55 
"all or nothing" approach to access. 



Sharing and Backup of Media 

An individual's access to an initialized media can be 
restored, or a second individual granted access, by 
5 bringing together the media, the requisite Personal Key- 
ing Device 30, and a Workstation 10 equipped with a 
Crypto Media Controller 26 that is keyed with the appro- 
priate Enclave Key. 

10 Positive Control of Privileged Operations 

Remotely invoked privileged operations at the 
Security Server 24 are under the positive control of the 
user 5. That control is cryptographtcally protected and 
15 mutually authenticated. 

TRUSTED PATH ALT ERNATE PREFERRED EMBOD- 
IMENT 

As also stated in the "Background of the Invention;' 
the Trusted Path can be used independently of the Data 
Enclave. Described below is a preferred embodiment of 
a Trusted Path that is preferably used to implement the 
Trusted Path operations of the Data Enclave, but which 
has utility independent of the Data Enclave invention. 
The Trusted Path of this embodiment can be used for 
security-relevant interactions between a human user 
and secure computer, which fall into four broad classes: 

1 . Identification and Authentication 

2. Trusted Command Initiation (privileged services) 

3. Trusted Review 

4. Key Management 

General Arrang ement 

A general arrangement of the Trusted Path is 
shown in Figure 29. This arrangement consists of four 
subsystems: Personal Unit 101, Workstation Unit 102, 
Untrusted Communications System 103, and part of 
Secure Computer 104. Personal Unit 101 communi- 
cates directly with Workstation Unit 102. Workstation 
Unit 102 communicates with Secure Computer 104 over 
Untrusted Communications System 103. It is the ele- 
ments of Untrusted Communications Systems 103 
which are the source of the various threats to secure 
operation. 

Personal Unit 101, Workstation Unit 102, Commu- 
nications Subsystem 103 and Secure Computer 104 
correspond in arrangement and at least general func- 
tion to the Personal Keying Device 30, Workstation 10, 
Networks 12 (and 16), and Security Server 24 of the 
Data Enclave 20, respectively. 
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Detailed Arrangement 
Workstation Without Encryption 

The Trusted Path comes in two forms, Workstations 5 
102 without encryption and Workstations 102 with 
encryption. The first form of the Trusted Path is for use 
with Workstations 102 that do not have a cryptographic 
unit, such as a Crypto Media Controller installed. In 
such Workstations 1 02 the key management function is 10 
not necessary. This form of the Trusted Path is illus- 
trated in Figure 30. 

Personai Unit . 

75 

Personal Unit 101 serves three purposes: 

(1) It serves to identify a human user and the Work- 
station used by that human user to Secure Compu- 
ter 104. 20 

(2) It is used by the human user to verify that pre- 
cisely those commands given by the human user to 
Secure Computer 104 are being executed by it, 
without tampering or modification by Urttrusted 
Communications System 103. 25 

(3) it is used by the human user to verify that critical 
and sensitive data in Secure Computer 104 is being 
displayed to the human user by Untrusted Commu- 
nications System 103 without tampering or modifi- 
cation. 30 

The human user 5 interacts with Personai Unit 101 
by means of Display 113 and Keyboard 114. Interac- 
tions are controlled by Logic and Control Unit 111. Per- 
sonal Unit 101 uses Communication Unit 118 to 35 
transmit and receive data to and from Communication 
Unit 128 in Workstation Unit 102. Communications can 
be by means of wire, radio, fiber optics, infrared, or any 
other medium capable of handling digital values. There 
are three areas of data storage in Personal Unit 101: 40 

(1) User Identifier 1 15 is a number which is uniquely 
assigned to each human user. The number can be 
stored in its entirety in User Identifier 15, or split 
between that storage and a value which is entered 45 
by the human user upon demand, i.e., a so-called 
Personal Identification Number or PIN. 

(2) Cryptographic Key Storage 116 is used to hold 
the keys used by Cryptographic Unit 1 12 to gener- 
ate keystream. These keys are selected and loaded so 
into Cryptographic Key Storage 116, when an 
instance of Personal Unit 101 is assigned to a 
human user. 

(3) Authentication Token Storage 1 17 is used in the 
Authentication Token Exchange Protocol, which is a ss 
unique feature of the Trusted Path. The working of 
this protocol is described later. 



Cryptographic Unit 1 1 2 must be logically compati- 
ble with Cryptographic Unit 142 in Secure Computer 
104; that is, given proper keying, it must be possible for 
one to decipher data which has been enciphered on the 
other. 

Personal Unit 101 is envisioned as being imple- 
mented by means which enable trust to be placed in it, 
and packaged in a manner which resists tampering or 
undetected modification. It is also envisioned to be 
implemented in a manner which enables it to be readily 
carried upon the person when not in use. 

Workstation Unit 

Workstation Unit 102 serves two purposes: 

1 . To identify a specific Workstation to Secure Com- 
puter 104. 

2. To logically connect Personal Unit 101 with 
Untrusted Communications System 103. 

Logic and Control Unit 121 controls Communica- 
tions Unit 128 and accesses Workstation Identifier 125 
when required. Workstation Identifier 125 is either a 
fixed value or is set by some mechanical means from 
the outside of Workstation Unit 102. it is envisioned that 
Workstation Unit 102, in this form, is implemented in a 
manner which enables it to be readily attached to exter- 
nal data ports of existing Workstations (e.g., RS232 
data port or so-called "games ports"). Workstation Unit 
102 is envisioned as being implemented by means 
which enable trust to be placed in it, and packaged in a 
manner which resists tampering or undetected modifi- 
cation. It is also envisioned as being packaged in a 
manner which permits rapid and reliable determination 
that it is properly attached to a designated Workstation. 

Untrusted Communications System 

Untrusted Communications System 103 consists of 
two logical parts: Workstation 131 and Network 132. 
Workstation 131 is a conventional workstation, personal 
computer, desk-top, lap-top, or palm -top computer with 
an external data port to which Workstation Unit 102 can 
be attached, and software which enables data to be 
passed between Workstation Unit 102 and Network 
132. 

Network 132 is any combination of local and/or 
wide area networks operating in conjunction with zero 
or more direct connections to form a data path between 
Workstation Unit 102 and Secure Computer 104. 

Secure Computer 

Security Kernel 143 controls access to Critical and 
Sensitive Data 144 according to a predefined security 
policy (e.g., based on clearances and classifications or 
notions of intellectual property or privacy). Logic and 
Control Unit 141 is a distinguished subsystem of Secure 
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Computer 104 which controls the interaction between 
Security Kernel 143 and Communication Unit 148. Such 
subsystems are sometimes called "terminal drivers", 
"device controllers", or "front-end processors". 

Logic and Control Unit 141 is enhanced with Cryp- 5 
tographic Unit 142 and the Authentication Token 
Exchange Protocol which is described later. Crypto- 
graphic Key Storage 146 is used to hold the crypto- 
graphic keys required for the operation of Cryptographic 
Unit 142. Cryptographic Unit 142 must be logically com- 10 
patible with Cryptographic Unit 112 in Personal Unit 
101 ; that is, given proper keying, it must be possible to 
decipher data which has been enciphered on the other. 

Security Kernel 143 is enhanced to perform the 
functions of Identification and Authentication, Trusted is 
Command Initiation, and Trusted Review. 

Workstations with Encryption 

The second form of the Trusted Path is for use in 20 
Workstations 102, which have a cryptographic unit 
installed, and where the Trusted Path facilities are used 
to authenticate the movement of cryptographic keys 
from the Secure Computer 104 to the Workstation Unit 
102. All operations supported in the previously 25 
described form are supported as well. This form of the 
Trusted Path is illustrated in Figure 31. 

The only difference in Personal Unit 1 01 in this form 
of the Trusted Path, is that Cryptographic Key Storage 
1 16 is expanded to hold cryptographic keys which are 30 
destined for Cryptographic Unit 122 in Workstation Unit 
112. 

All of the previous functions of Workstation Unit 102 
are supported. In addition, Cryptographic Unit 122 is 
provided to protect Critical and Sensitive Data 144 resi- 35 
dent on fixed and removable media from theft, tamper- 
ing, or unauthorized access. Cryptographic Unit 122 
may or may not be physically or logically identical with 
Cryptographic Units 112 and 142. The basic functions 
and operation of Workstation 1 02 are as described ear- 40 
Her. 

Untrusted Communications System 103 is 
unchanged from the previous form. 

All previous functions of Secure Computer 104 are 
retained and Security Kernel 143 is enhanced to per- 45 
form the additional functions of Workstation Key Man- 
agement as described earlier. 

General Operation of Trusted Path 

50 

Following is a description of the operation of the 
Trusted Path. A general, overview description of the pro- 
tocols is given first, followed by a detailed description of 
the Trusted Path operation and the significance of the 
protocols. 55 

Any physical communications protocols which are 
appropriate for the media connecting Communications 
Units 118 and 128, Communications Unit 128 and 
Workstation 131, and Network 132 and Communica- 



tions Unit 148 can be used in the operation of the inven- 
tion. . 

Authentication Token Exchange Protocol 

The Authentication Token Exchange Protocol is an 
end-to-end authentication protocol which is used to 
assure Logic and Control Unit 1 1 1 is interacting with an 
Authentic Logic and Control Unit 141 and vice versa. 
The protocol operates by "chaining" transactions 
together in such a fashion that a forged transaction that 
is entered into the interaction, will be detected the very 
next time a legitimate transaction is received by Logic 
and Control Unit 141. The Authentication Token 
Exchange Protocol is described in detail later. 

Cryptographic Checksum Protocol 

The Cryptographic Checksum Protocol is an addi- 
tional protocol which is used to assure transactions 
between Logic and Control Units have not been tam- 
pered with. The Cryptographic Checksum Protocol dif- 
fers from the Authentication Token Exchange Protocol 
in that it authenticates single transactions rather than 
sequences of transactions. Any cryptographic check- 
sum or digital signature algorithm which meets reason- 
able standards of cryptographic strength can be used in 
the present invention, 

Identification and Authentication Protocol 

The Identification and Authentication Protocol is 
invoked when a user wishes to interact with Secure 
Computer 104 for some period of time, using the key- 
board and display of Workstation 131 and the communi- 
cations facilities of Network 132. The period of 
interaction is commonly called a session, the act of ini- 
tiating a session is commonly called logon, and that of 
terminating one is commonly called logout In addition, 
the Identification and Authentication Protocol may be 
restarted by Secure Computer 104 when the user 
requests some critical operation be performed. 

The general operation of the Identification and 
Authentication Protocol, given with general reference to 
Figures 30-33, is as follows: 

Step 1 

The user establishes a physical communica- 
tions link between Personal Unit 101 and Worksta- 
tion Unit 102. If the communications media is wired, 
this will involve connecting the two units. If it is wire- 
less, it will involve placing the units in proper physi- 
cal proximity. 

Step 2 

The user presses an attention key on Personal 
Unit 101 and optionally enters a Personal Identifica- 
tion Number. Personal Unit 101 obtains Worksta- 
tion Identifier 125 from Workstation Unit 102, 
constructs an Identification and Authentication 
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Transaction, and causes rt to be transmitted to 
Secure Computer 104. 
Step 3 

Secure Computer 104 verifies that this is an 
authentic Identification and Authentication Transi- 5 
tion and begins a new session or other interaction 
- with the user. 
Step 4 

Secure Computer 104 constructs an Acknowl- 
edgment Transaction and causes it to be sent to io 
Personal Unit 101. 
Steps 

Personal Unit 101 verifies that this is an 
authentic Acknowledgment Transaction and dis- 
plays this fact to the user. rs 

Individual transactions in the Identification and 
Authentication Protocol are authenticated by the 
Cryptographic Checksum Protocol. The fact that a 
given Identification and Authentication transaction 
is occurring in the proper context is authenticated 20 
by the Authentication Token Exchange Protocol. 
The Identification and Authentication Protocol is 
described in detail later. 

Trusted Command Protocol 25 

The Trusted Command Protocol is invoked when a 
user wishes to exercise some privilege or cause Secure 
Computer 1 04 to perform some security-relevant opera- 
tion. The general operation of the Trusted Command 30 
Protocol, given with general reference to Figures 30-33, 
is as follows: 

S tepi 

The user, operating in conjunction with soft- 35 
ware in Workstation 131, selects the desired com- 
mand from a menu of possible commands. 
Selection can be by means of a keyboard, mouse, 
or other input device that is part of the normal oper- 
ation of Workstation 131. 40 
Step 2 

The software in Workstation 131 transmits the 
selected command to Personal Unit 101 . 
Step 3 

Personal Unit 101 displays the selected com- 45 
mand to the user. 
Step 4 

The user verifies that the displayed command 
is that which he or she selected and so signifies on 
the keyboard of Personal Unit 101 . so 
Steps 

Personal Unit 101 constructs a Trusted Com- 
mand Transaction and causes it to be transmitted to 
Secure Computer 104. 

Step 6 55 

Secure Computer 104 verifies that this is an 
authentic Trusted Command Transaction, executes 
the appropriate command, constructs an Acknowl- 



edgment Transaction and displays this fact to the 

user. 

Step 7 

Personal Unit 101 verifies that this is an 
authentic Acknowledgment Transaction and dis- 
plays this fact to the user. 

Individual transactions in the Trusted Command 
Protocol are authenticated by the Cryptographic Check- 
sum Protocol. The fact that a given Trusted Command 
Transaction is occurring in the proper context is authen- 
ticated by the Authentication Token Exchange Protocol. 
The Trusted Command Protocol is described in detail 
later. 

Trusted Review Protocol 

The Trusted Review Protocol is used when a user 
wishes to be assured that an element of critical and 
sensitive data displayed on Workstation 131 is an accu- 
rate and proper representation of the critical and sensi 
tive data as stored in Secure Computer 104. The 
general operation of the Trusted Review Protocol, given 
with general reference to Figures 30 - 33, is as follows: 

Steal 

The user causes the relevant element of critical 
and sensitive data to be transmitted from Secure 
Computer 104 and displayed on Workstation 131. 
Step 2 

By means of software in Workstation 131, the 
user selects the portion of critical and sensitive data 
whose representation is to be verified. 
Ste p 3 

Software in Workstation 131 transmits the 
boundaries of the selected portion to Secure Com- 
puter 104. 
Step 4 

Secure Computer 104 extracts the critical and 
sensitive data which resides within the selected 
boundaries, places it in one or more Trusted 
Review Transactions, and causes it to be transmit- 
ted to Personal Unit 101. 
Steps 

Personal Unit 101 verifies the authenticity of 
the Trusted Review Transactions and displays the 
selected portion of critical and sensitive data on its 
own display. 
Step 6 

The user verifies that the values displayed on 
Personal Unit 101 are identical to those displayed 
on Workstation 131 and acknowledges this fact 
using the keyboard of Personal Unit 101. 
Step 7 

Personal Unit 101 sends an Acknowledgment 
Transaction to Secure Computer 104. 

Individual transactions in the Trusted Review 
Protocol are authenticated by the Cryptographic 
Checksum Protocol. The fact that a given Trusted 
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Review Transaction is occurring in the proper con- 
text is authenticated by the Authentication Token 
Exchange Protocol. The Trusted Review Protocol is 
described in detail later. 

Workstation Key Management Protocol 

The Workstation Key Management Protocol is a 
form of the Trusted Command Protocol and is used in 
the form of the present invention where the critical and 
sensitive data stored on the individual Workstations is to 
be protected by cryptography, as for example, in the 
Data Enclave System 20 described above. The Work- 
station Key Management Protocol is used to provide 
authenticated distribution of cryptographic keys from 
Secure Computer 104 to individual Workstation Units 
102. The general operation of the protocol, given with 
general reference to Figures 30 - 33, is as follows: 

Step 1 

The user approaches the selected Workstation 
and initiates the Identification and Authentication 
Protocol. 
Step 2 

Workstation Unit 102 identifies the unit of 
media for which a cryptographic key is required and 
transmits this identification to Personal Unit 101. 
The identification is based on the "volume identifier" 
or other unique designator which is carried on the 
media. If the media has not been initialized, this 
information is transmitted to Personal Unit 101. 
Step 3 

Personal Unit 101 constructs a Key Request 
Transaction and causes it to be transmitted through 
Workstation Unit 102 and Subsystem 103 to 
Secure Computer 104. 
Step 4 

Secure Computer 104 verifies that this is an 
authentic Key Request Transaction, selects the 
appropriate key from a database kept as critical and 
sensitive data, or creates a new key in the case of 
uninitialized media, and causes the key to be trans- 
mitted to Personal Unit 101. 
Step 5 

Personal Unit 101 verifies that this is an 
authentic key, transmits it to the proper Workstation 
Unit 102, and displays the successful completion of 
the keying process to the user. 

Cryptographic keys are protected during transmis- 
sion by being enciphered in a Key Encryption Key, for 
example (Enclave Key 40), which is loaded into each 
Workstation Unit 102 when they are installed. Individual 
transactions in the Workstation Key Management Proto- 
col are authenticated by the Cryptographic Checksum 
Protocol. The fact that a given Key management Trans- 
action is occurring in the proper context is authenticated 
by the Authentication Token Exchange Protocol. 



Thus, the Key Generation and Assignment proto- 
cols described with respect to Data Enclave 20 operate 
substantially the same as the Key Management Proto- 
col with the exception that, in the Key Management Pro- 
s tocol, all interactions between the secure computer and 
the Workstation are validated by the Authentication 
Token Exchange protocol and users are identified using 
the Identification and Authentication Protocol. 

10 DETAILED OPERATION OF TRUSTED PATH 

Those operations which are individually unique to 
the present invention are described in detail. These are 
the Authentication Token Exchange Protocol, the (denti- 
ns fication and Authentication Protocol, the Trusted Com- 
mand Protocol, the Trusted Review Protocol, and the 
Workstation Key Management Protocol. 

Authentication Token Exchange Protocol 

20 

The Authentication Token Exchange Protocol 
makes use of two pseudo-random sequences of num- 
bers: a Synchronized Keystream and an Authentication 
Token Sequence. 

25 

Synchronized Keystreams 

Synchronized Keystreams are produced by Crypto- 
graphic Units 112 and 142. The logic of these units is 

30 shown in Figure 32. The actual keystreams are pro- 
duced by algorithms in Keystream Generators 201 and 
221 . The sequence of numbers (called "Keystream Ele- 
ments") in the keystream is a function of the crypto- 
graphic key kept in Cryptographic Key Buffers 202 and 

35 222. The manner in which the keystream is generated 
may differ between the two units, but the resulting key- 
streams must be identical for the protocol to operate. In 
particular, a large, precomputed keystream sequence 
may be stored in Cryptographic Key Buffer 202 or 222 

40 and simply copied by the respective Keystream Gener- 
ator 201 or 221. (This technique is sometimes called a 
"one-time pad.") Alternatively, a much shorter crypto- 
graphic key may be used to "seed" the mechanism in 
Keystream Generator 201 or 221, and the keystream 

45 produced in small quantities as required. 

A low-level synchronization protocol is required to 
handle cases when transmission errors or other difficul- 
ties cause the keystreams to lose synchronization. 
Such protocols make use of well-known techniques and 

so are not described here. 

Encryption is effected by combining the keystream 
with the data in Combining/Decombining Units 203 and 
223. These units may use methods such as "exclusive 
OR," module addition, or other well-known techniques. 

55 Decryption is effected by performing the inverse opera- 
tion using identical keystream values. It is required for 
operation of the present invention that not only are the 
keystreams in Cryptographic Units 112 and 142 identi- 



18 



35 



EP 0 737 907 A2 



36 



cal and synchronized, but that the techniques used for 
combining keystream with data be identical. 

Authentication Token Sequence 

5 

The Authentication Token Sequence is produced 
inside Secure Computer 104 by Authentication Token 
Generator 147 (Figures 30 and 31). The Authentication 
Tokens are generated in some fashion that makes it 
computationally infeasible to predict. What the value of 10 
the next token in the sequence should be is based on 
the value of the given token. The nature of the Authenti- 
cation Token Exchange Protocol is such that no syn- 
chronization of the sequence with any other unit is 
required. Authentication Token Generator 147 also 75 
maintains a history file of Authentication Tokens for 
some preset interval. This history is used to differentiate 
masquerade attempts from alarms caused by faulty 
transmission or equipment failures. There is one 
Authentication Token Sequence for each user or other 20 
distinguished operating entity. 

Authentication Token Exchange Protocol 

The steps used by the Authentication Token 25 
Exchange Protocol to "chain" together transactions of 
other protocols are shown in Figure 33. The steps 
described below are keyed to that figure. Note that this 
protocol is for the generation and validation of tokens 
which appear as data fields in the transactions of other 30 
protocols. The description of each step that follows is 
also referenced to Figures 30 - 32. 

Ste pi 

The initial state of a protocol cycle is one in 35 
which Personal Unit 101 contains a value from 
some previous transaction and Secure Computer 
104 is preparing to initiate a new transaction. The 
Authentication Token Sequence has just generated 
Token Number m, and the Synchronized Keystream 40 
Sequences have just produced Keystream Element 
n. In such a case, the Authentication Token Storage 
1 17 will contain a value which is the result of enci- 
phering Token m with Keystream Element n. Key- 
stream Generators 201 and 221 will be ready to 45 
generate Keystream Element n+1, and Authentica- 
tion Token Generator 1 47 will be ready to generate 
Token m+1 . 
Step 2 

A single cycle of the Authentication Token so 
Exchange Protocol is initiated when some transac- 
tion is to be sent from Secure Computer 1 04 to Per- 
sonal Unit 101. In this case, Logic and Control Unit 
141 commands Authentication Token Generator 
147 to generate a token (in this case m+1) and ss 
commands Cryptographic Unit 142 to encipher it (in 
this case, with Keystream Element n+1). The enci- 
phered token is then transmitted to Personal Unit 
101 as a data field in a transaction record. Arrival of 



the transaction causes Personal Unit 101 to per- 
form the next step in the cycle. 
Step 3 

Logic and Control Unit 1 1 1 causes the value 
stored in Authentication Token Storage 117 to he 
deciphered by Cryptographic Unit 112 using Key- 
stream Element n; this yields the true value of 
Token m. Logic and Control Unit 1 1 1 then immedi- 
ately commands Cryptographic Unit 1 12 to re-enci- 
pher Token m using Keystream Element n+2. The 
enciphered value is then returned to Secure Com- 
puter 104 in whatever transaction is used to "echo" 
or acknowledge the transaction sent from Secure 
Computer 104 to Personal Unit 101 in Step 2. 
Step 4 

Logic and Control Unit 141 then causes the 
incoming enciphered value to be deciphered by 
Cryptographic Unit 142 using Keystream Element 
n+2. This yields the value of the putative Token m 
which has cycled from Secure Computer 104 to 
Personal Unit 101 and back again. 
Steps 

The putative Token m value is then compared 
by Logic and Control Unit 1 41 with the value that 
has been retained by Authentication Token Genera- 
tor 147. If the values are the same, the Logic and 
Control Unit 141 is assured that the incoming trans- 
action was property "chained" to an outgoing one 
and is not erroneous or forged. If the values are not 
the same. Logic and Control Unit 141 invokes the 
low-level synchronization protocol to cause retrans- 
mit of the records. If some preset number of trans- 
missions fails to yield an authenticated "chaining" 
then the Logic and Control Unit 141 raises an 
alarm. 
Step 6 

Simultaneously with Step 5, Logic and Control 
Unit 111 in Personal Unit 101 updates Authentica- 
tion Token Storage 1 17 with the new value, which is 
Token m+1 enciphered with Keystream Element 
n+1. At this point the protocol cycle has completed 
and the protocol is back in its initial state awaiting 
the start of a new cycle. 

The low-level synchronization protocol may require 
that Authentication Token Storage Unit 147 keep a "win- 
dow" of old values, so that a period of time exists in 
which a previous value can be retransmitted to Secure 
Computer 1 04 in cases where the comparison 
described in Step 5 fails. 

Identification and Authentication Protocol 

The Identification and Authentication Protocol oper- 
ation is identical for both forms of the present invention. 
The description that follows is referenced to Figures 30 
and 31. 
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Initiation of Protocol 

The protocol is initiated when a user first estab- 
lishes a communications link between Personal Unit 
101 and Workstation Unit 102, when a user initiates an 5 
"attention" signal by pressing a key on Keyboard 1 14, or 
when a demand for user authentication is made by 
Secure Computer 1 04. 

If the protocol was initiated from Personal Unit 101 , 
an Initiation Transaction is constructed by Logic and 10 
Control Unit 111 consisting of the following elements: 

(1) A distinguished value identifying this as an Initi- 
ation Transaction. 

(2) A value which will enable Logic and Control Unit 75 
141 to reply to the transaction (e.g., a network 
address). 

(3) User Identifier 115, enciphered with a key- 
stream which is reserved for this purpose. 

(4) A value provided by the Cryptographic Check- 20 
sum Protocol which serves to validate the value 
and association of the above elements. 

Authentication Demand Transaction 

25 

Upon receipt of the Initiation Transaction, or upon 
demand by Security Kernel 143 for user authentication, 
Logic and Control Unit 141 constructs an Authentication 
Demand Transaction and transmits it to Logic and Con- 
trol Unit 111. This transaction consists of the following 30 
elements: 

(1) A distinguished value identifying this as an 
Authentication Demand Transaction. 

(2) An enciphered Authentication Token as 35 
described in Step 2 of the Authentication Token 
Exchange Protocol. If this transaction is in 
response to an Initiation Transaction, the User Iden- 
tifier 1 15 in that transaction will be deciphered and 
used to select the proper sequence of Authentica- 40 
tion Tokens. If this transaction is in response to a 
demand from Security Kernel 143, the user identi- 
fier (and therefore the denotation of the proper 
Token Sequence) will be included in the demand. 

3. A value from the Cryptographic Checksum Proto- 45 
col which serves to authenticate the value and 
association of the above elements. 

Authentication Response Transaction 

50 

Upon receipt of this transaction, Logic and Control 
Unit 111 notifies the user by means of Display 113. If 
required, user enters a Personal Identification Number 
or other value or measurement which serves to identify 
the user. Logic and Control Unit 1 11 communicates with 55 
Logic and Control Unit 121 and obtains from it Worksta- 
tion Identifier 125. Logic and Control Unit 111 then con- 
structs and sends to Logic and Control Unit 141 an 



Authentication Response Transaction which consists of 
the following elements: 

(1) A distinguished value identifying this as an 
Authentication Response Transaction. 

(2) The Workstation Identifier 125, enciphered with 
a keystream reserved for this purpose. 

(3) The User Identifier 115, optionally supple- 
mented with Personal Identification Number or 
other personal data, and enciphered with a key- 
stream reserved for this purpose. 

(4) An enciphered return Authentication Token as 
described in Step 3 of Authentication Token 
Exchange Protocol. 

(5) A value from the Cryptographic Checksum Pro- 
tocol which serves to authenticate the value and 
association of the above elements. 

Upon receipt of this transaction, Logic and Control 
Unit 141 deciphers Workstation Identifier 125 and User 
Identifier 115, performs the operations described in 
Steps 4 and 5 of the Authentication Token Exchange 
Protocol, and if validated, notifies Security Kernel 143 
that the denoted user interacting from the denoted 
Workstation has been authenticated. If not validated, 
Logic and Control Unit 141 notifies Security Kernel 143 
that an invalid logon attempt has occurred and appropri- 
ate response should be made. 

Acknowledgment Transaction 

If the validation succeeds, Logic and Control Unit 
141 constructs and sends to Logic and Control Unit 1 1 1 
an Acknowledgment Transaction which consists of the 
following elements: 

(1) A distinguished value identifying this as an 
Acknowledgment Transaction. 

(2) The Workstation Identifier 125 and User Identi- 
fier 115, enciphered with the next element of the 
keystream reserved for this purpose. 

(3) A value from the Cryptographic Checksum Pro- 
tocol which serves to authenticate the value and 
association of the above elements. 

Validation of Response 

Upon receipt of this transaction, Logic and Control 
Unit 111 performs Step 6 of the Authentication Token 
Exchange Protocol, notifies the user by means of Dis- 
play 113 that the identification and authentication proc- 
ess is complete, and sends a transaction to Workstation 
131 through Communications Units 118 and 128 that 
causes communications between Workstation 131 and 
Secure Computer 104 to be initiated in the case of 
logon, or to be continued in the case of an identification 
demand from Secure Computer 104 in the middle of a 
session. 
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Trusted Command Protocol 

The Trusted Command Protocol operation is identi- 
cal for both forms of the present invention. The descrip- 
tion that follows is referenced to Figures 30 and 31 . s 

The protocol is initiated when a user selects a priv- 
ileged command when interacting with Workstation 131 . 
The privileged nature of the command is recognized by 
Security Kernel 143 and it notifies Logic and Control 
Unit 141 to start the protocol for the selected privileged io 
command. 

User Confirmation Demand Transaction 

Logic and Control Unit 1 41 constructs and sends to is 
Logic and Control Unit 111 a User Confirmation 
Demand Transaction which consists of the following ele- 
ments: 

(1) A distinguished value identifying this as a User 20 
Confirmation Demand Transaction. 

(2) An enciphered Authentication Token as 
described in Step 2 of the Authentication Token 
Exchange Protocol. 

(3) A description or denotation of the privileged 2s 
command and the relevant parameters formatted, 

so it may be displayed on Display 1 1 3 of Personal 
Unit 101. 

(4) A value from the Cryptographic Checksum Pro- 
tocol which serves to authenticate the value and so 
association of the above elements. 

User Response Transaction 

Upon receipt of this transaction, Logic and Control 35 
Unit 1 1 1 displays the description or denotation of the 
privileged command on Display 113. The user visually 
checks that the description as displayed is of the com- 
mand whose selection initiated the protocol, and notifies 
Logic and Control Unit 111 through Keyboard 114, 40 
whether the selection of the command is confirmed or 
denied. Upon receipt of this notification, Logic and Con- 
trol Unit 1 1 1 constructs a User Response Transaction 
which consists of the following elements: 

45 

(1) A distinguished value identifying this as a User 
Response Transaction. 

(2) An indication of whether the command selection 
is confirmed or denied, enciphered using a key- 
stream reserved for this purpose. so 

(3) An enciphered return Authentication Token as 
described in Step 3 of Authentication Token 
Exchange Protocol. 

(4) A value from the Cryptographic Checksum Pro- 
tocol which serves to authenticate the value and ss 
association of the above elements. 



Immediately subsequent to the sending of this 
transaction, Logic and Control Unit 1 1 1 performs Step 6 
of the Authentication Token Exchange Protocol. 

Upon receipt of the User Response Transaction, 
Logic and Control Unit 141 deciphers the confirm/deny 
indicator and performs Steps 4 and 5 of the Authentica- 
tion Token Exchange protocol. Logic and Control Unit 
141 passes the confirm/deny indicator to Security Ker- 
nel 143. ff confirm, the command is executed and Logic 
and Control Unit 141 is so notified. If deny, Security Ker- 
nel 143 takes appropriate action such as retry or alarm. 

Acknowledgment Transaction 

If the command is invoked, Logic and Control Unit 
141 constructs and sends to Logic and Control Unit 111 
an Acknowledgment Transaction which consists of the 
following elements: 

(1) A distinguished value identifying this as an 
Acknowledgment Transaction. 

(2) An enciphered Authentication Token as 
described in Step 2 of the Authentication Token 
Exchange Protocol. 

(3) A value from the Cryptographic Checksum Pro- 
tocol which serves to authenticate the value and 
association of the above element. 

Notification Complete Transaction 

Upon receipt of this transaction, Logic and Control 
Unit 111 displays the acknowledgment on Display 113. 
Logic and Control Unit 1 1 1 then constructs and sends 
to Logic and Control Unit 141, a Notification Complete 
Transaction which consist of the following elements: 

(1) A distinguished value identifying this as a Notifi- 
cation Complete Transaction. 

(2) An enciphered return Authentication Token as 
described in Step 3 of Authentication Token 
Exchange Protocol. 

(3) A value from the Cryptographic Checksum Pro- 
tocol which serves to authenticate the value and 
association of the above elements. 

Immediately subsequent to the sending of this 
transaction, Logic and Control Unit 1 1 1 performs Step 6 
of the Authentication Token Exchange Protocol. 

Upon receipt of this transaction, Logic and Control 
Unit 141 performs Steps 4 and 5 of the Authentication 
Token Exchange Protocol and communicates to Secu- 
rity Kernel 143 that the user has been notified. 

Trusted Review Protocol 

The Trusted Review Protocol operation is identical 
for both forms of the present invention. The description 
that follows is referenced to Figures 30 and 31 . 
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The protocol is initiated when a user invokes a 
Trusted Review Command from Workstation 131 . Secu- 
rity Kernel 143 recognizes this command and displays, 
subject to the restrictions of security policy, a window of 
information on its screen using the conventions of 5 
graphical or other user interlaces. Within this window, 
Security Kernel 143 also displays a review subwindow 
whose dimensions are such that all the data displayed 
on it can be identically displayed on Display 1 13 of Per- 
sonal Unit 101. The position of the review subwindow 10 
can be moved within the main window using the key- 
board, mouse, or other input device of Workstation 131 . 
This arrangement is shown in Figure 34. 

User Review Demand Transaction 75 

When the user is satisfied that the review subwin- 
dow 1 34* is positioned over the portion of critical and 
sensitive data to be reviewed, he or she notifies Security 
Kernel 143 by means of the keyboard or other input 20 
device on Workstation 131. Security Kernel 143 copies 
the portion of critical and sensitive data to be reviewed 
from Critical and Sensitive Data 144 and sends it to 
Logic and Control Unit 141. Logic and Control Unit 141 
then constructs and sends to Logic and Control Unit 25 
111a User Review Demand Transaction which consists 
of the following elements: 

(1) A distinguished value identifying this as a User 
Review Demand Transaction. 30 

(2) An enciphered Authentication Token as 
described in Step 2 of the Authentication Token 
Exchange Protocol. 

(3) The portion of critical and sensitive data format- 
ted, so it may be displayed on Display 1 13 of Per- 35 
sonal Unit 101. 

(4) A value from the Cryptographic Checksum Pro- 
tocol which serves to authenticate the value and 
association of the above elements. 

40 

User Response Transaction 

Upon receipt of this transaction, Logic and Control 
Unit 1 1 1 displays the portion of critical and sensitive 
data on Display 113. The user visually checks that the 45 
portion as displayed, is identical to that shown on the 
review subwindow, and notifies Logic and Control Unit 
111 through Keyboard 114 whether the review is con- 
firmed or denied. Upon receipt of this notification, Logic 
and Control Unit 111 constructs a User Response so 
Transaction which consists of the following elements: 

(1) A distinguished value identifying this as a User 
Response Transaction. 

(2) An indication of whether the review is confirmed 55 
or denied, enciphered using a keystream reserved 

for this purpose. 



(3) An enciphered return Authentication Token as 
described in Step 3 of Authentication Token 
Exchange Protocol. 

(4) A value from the Cryptographic Checksum Pro- 
tocol which serves to authenticate the value and 
association of the above elements. 

Immediately subsequent to the sending of this 
transaction, Logic and Control Unit 1 1 1 performs Step 6 
of the Authentication Token Exchange Protocol. 

Upon receipt of the User Response Transaction, 
Logic and Control Unit 141 deciphers the confirm/deny 
indicator and performs Steps 4 and 5 of the Authentica- 
tion Token Exchange Protocol. Logic and Control Unit 
141 passes the confirm/deny indicator to Security Ker- 
nel 143. If confirm, processing proceeds and Logic and 
Control Unit 141 is so notified. If deny, Security Kernel 
143 takes appropriate action such as retry or alarm. 

Acknowledgment Transaction 

If the command is invoked, Logic and Control Unit 
141 constructs and sends to Logic and Control Unit 1 1 1 
an Acknowledgment Transaction which consists of the 
following elements: 

(1) A distinguished value identifying this as an 
Acknowledgment Transaction. 

(2) An enciphered Authentication Token as 
described in Step 2 of the Authentication Token 
Exchange Protocol. 

(3) A value from the Cryptographic Checksum Pro- 
tocol which serves to authenticate the value and 
association of the above elements. 

Notification Complete Transaction 

Upon receipt of this transaction, Logic and Control 
Unit 1 1 1 displays the acknowledgment on Display 1 13. 
Logic and Control Unit 1 1 1 then constructs a Notifica- 
tion Complete Transaction which consists of the follow- 
ing elements: 

(1) A distinguished value identifying this as a Notifi- 
cation Complete Transaction. 

(2) An enciphered return Authentication Token as 
described in Step 3 of Authentication Token 
Exchange Protocol. 

(3) A value from the Cryptographic Checksum Pro- 
tocol which serves to authenticate the value and 
association of the above elements. 

Immediately subsequent to the sending of this 
transaction, Logic and Control Unit 1 1 1 performs Step 6 
of the Authentication Token Exchange Protocol. 

Upon receipt of this transaction, Logic and Control 
Unit 141 performs Steps 4 and 5 of the Authentication 
Token Exchange Protocol and communicates to Secu- 
rity Kernel 143 that the user has been notified. 
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Advantages of Trusted Path 

Centralized Detection of Security Alarms 

The protocols of the invention are arranged so that 
all security alarms are raised at Secure Computer 104 
and there is no user responsibility for responding to an 
alarm. This feature is an improvement over traditional 
cryptographic Checksum and other means which dis- 
play alarms to users and require them to notify the 
proper authorities, in that it permits the invention to pro- 
vide security for users who may be in physical locations 
where such notification is not possible. 

Robustness 

If an attacker obtains an actual Personal Unit 101 or 
its logical equivalent, and obtains through analysis or 
subversion of personnel the keystream used in the 
Authentication Token Exchange Protocol, the protocol 
allows him a "window of opportunity" for masquerade 
which is terminated the very next time the legitimate 
user and Personal Unit 101 interacts with Secure Com- 
puter 104. This is because each interaction moves the 
sequence of Authentication Tokens inside Secure Com- 
puter 104, and this movement cannot be influenced 
from the outside. (If Secure Computer 104 is compro- 
mised, then all data is lost, anyway). The operation per- 
formed by the masquerading attacker will cause a 
mismatch in the return Token when the legitimate user 
attempts an interaction, and this mismatch will be 
detected at Secure Computer 104. 

This robustness enables the user of weaker crypto- 
graphic algorithms or keys in environments where it is 
not safe or desirable to transport or use high-grade 
cryptography. 

Positive Detection of Attack 

The Authentication Token Exchange Protocol is 
superior to traditional methods which rely on crypto- 
graphic checksums, in that it can positively differentiate 
between alarms raised by communications failures and 
those raised by deliberate attempts to compromise 
security. This capability is granted by the Authentication 
Token sequence. If a mismatch in Tokens is detected in 
Step 5 of the Authentication Token Exchange Protocol, 
then the Token sequence can be searched backward to 
see if the returned Token matches exactly some earlier 
value. If it does, then Secure Computer 104 is assured, 
to the strength of the algorithm that randomizes the 
Tokens, that the alarm was raised by an attack. In addi- 
tion, Secure Computer 104 knows that the keystream 
used in the Authentication Token Exchange Protocol 
has been compromised, and can identify the exact inter- 
action where the compromise occurred. 



Positive Determination of Security Boundaries 

The elements of the invention provide physical and 
verifiable indications of where the security boundaries 
5 of Secure Computer 104 are located. 

Operational Advantages 

Independence of Communications Means 

10 

The protocols in this invention operate at Layer 5, 6, 
and 7 of the ISO standard lor communications proto- 
cols. This means that they are independent of the 
nature of topology of the network which connects Work- 
15 station 131 to Secure Computer 104. All prior means for 
achieving Trusted Path have depended, on a greater or 
lesser degree, on the nature or topology of this network. 

Minimal Intrusiveness 

20 

The elements of the invention are either free-stand- 
ing units, parts of an already distinguished secure com- 
puter, or devices which attach to existing interfaces to 
commercial workstations. The only modification 

25 required to a commercial workstation is a software mod- 
ification so that data can pass from Workstation Unit 2 
across the network to Secure Computer 104. No secu- 
rity reliance is placed on this modification, so that it can 
be rapidly and economically made to the software of a 

30 wide variety of commercial units. 

Low Cost 

The elements of the invention are such that they 
35 can be constructed of readily available commercial 
technology. 

ALTERNATE EMBODIMENT OF DATA ENCLAVE 
SYSTEM 

40 

An alternate embodiment of the Data Enclave Sys- 
tem 20 is shown in Figs. 35, 36 and 37. Alternate 
embodiment 300 provides for operation of the Data 
Enclave System in a non-networked environment. 

45 

Data Elements 

The data elements of the alternate embodiment 
300 correspond to those described with reference to 
so embodiment 20. 

Processing Elements 

Crypto Support Center 

55 

A Crypto Support Center 310 is provided for each 
organization or set of organizations. The Crypto Sup- 
port Center 310 is used for archival storage and distri- 
bution of cryptographic keys. Crypto Support Center 
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310 is permanently installed in a secure area, and 
includes a Secure Computer 311 and a Communica- 
tions Security Device 312. Secure Computer 311 may 
be of generally the same design as Security Server 24 
as described and illustrated with reference to embodi- 
ment 20. However, there is no requirement that the 
Secure Computer 311 be networked to the work sta- 
tions 340 within the organization. 

Local Cr ypto Support Dfl v/irg 

There is at least one local Crypto Support Device 
320 for each organization. Each local Crypto Support 
Device 320 is portable, for example, lap-top computer 
size. Preferably, local Crypto Support Devices 320 are 
equipped with theft detection circuitry such as that used 
to deter shoplifting. Local Crypto Support Devices 320 
are used in key distribution and are equipped with a 
Communications Security Device 322 that is compatible 
with the Communication Device 312 in Crypto Support 
Center 310. Local Crypto Support Device 320 includes 
a Key Management Crypto 324 which functions sub- 
stantially the same as the Key Management Crypto 70 
described with reference to the embodiment 20 of the 
data enclave system, insofar as media initialization, key 
generation and key assignment are concerned. Crypto 
Support Devices 320 further include a disk drive 326, 
which may be used to read and write removable media 
302, and a data interface 328, which may be coupled to 
a Crypto Media Controller in a Workstation 340. The 
interface can either be wired or wireless (for example, 
radio infra-red). 

Personal Keying Davine 

Each user is issued a Personal Keying Device 330 
of the same design as Personal Keying Device 30 
described above with reference to embodiment 20 of 
the Data Enclave System. Personal Keying Device 330 
is used for key insertion and individual authentication. 
Personal Keying Device 330 includes electronic storage 

331 , a key pad, a display and a Data Transfer Interface 

332, which is compatible with the Data Transfer Inter- 
face in the local Crypto support device 320. Personal 
Keying Devices 330 may also be equipped with theft 
detection circuitry. 

Crypto Media Controller 

Each work station 340 operating within the enclave 
300 includes a Crypto Media Controller 342 of the same 
design as Crypto Media Controller 26, with the excep- 
tion that Crypto Media Controller 342 does not include 
logic and functions for media initialization and key gen- 
eration, or key assignment for already initialized media. 
Crypto Media Controller 342 further includes a Data 
Interface 344 compatible with Data Interface 328 in the 
Local Crypto Support Device 320. 



OPERATION OF ALTERNATE EMBODIMENT 300 

Alternate embodiment 300 is similar in many 
respects to embodiment 20, except that Local Crypto 

5 Support Device 320 and Crypto Support Center 310 
perform certain functions performed by Crypto Media 
Controller 26 and Security Server 24, respectively, 
embodiment 20. Namely, those functions described in 
Steps 1 - 13 of the Media Initialization and Key Genera- 

10 tion and the Key Assignment process (for initialized 
media) Steps 1 - 14 of embodiment 20. In addition, the 
Local Area Network 12 link used in embodiment 20 is 
replaced with the secure connection established 
between Communications Security Devices 312 and 

75 322 in the Local Crypto Support Device 320 and Crypto 
Support Center 310. 

Media Initialization and Kev Assignment 

20 The following description of the media initialization 
and key assignment operation refers to Figs. 36 and 37. 

An individual brings together a blank unit of physi- 
cal media 302, his or her Personal Keying Device 330, 
and the appropriate Local Crypto Support Device 320. If 

25 the media is fixed, Personal Keying Device 330 and 
local Crypto support device 320 are brought to the 
Workstation 340 containing the fixed media 302. As 
shown in Fig. 36, data interfaces are then established 
between Personal Keying Device 330 and Local Crypto 

30 Support Device 320 on the one hand and in between 
Local Crypto Support Device 320 and the Crypto Media 
Controller 342 for the fixed media on the other. Once 
these interfaces are established, a secure link is made 
between Local Crypto Support Device 320 and Crypto 

35 Support Center 310 using the Communication Security 
Devices 312 and 322. The Trusted Path Protocol of the 
present invention may be used to establish a secure 
link. 

If the media 302 is removable, the media 302 is 

40 brought to the Local Crypto Support Device 320, where 
it can be read and written using Disk Drive 326. This 
configuration is shown in Figure 37. 

The individual desiring access to Media 302 then 
enters his or her PIN 58 into Personal Keying Device 

45 330 which transmits it to Local Crypto Support Device 
320. Local Crypto Support Device 320 extracts the 
encrypted User UID 56 from Personal Keying Device 
330 and decrypts it using the Enclave Key 50. 

Local Crypto Support Device 320 then initiates a 

so secure connection to the Crypto Support Center 310 
and transmits the User UID 56 to it. 

Local Crypto Support Device 320 and the Crypto 
Support Center 310, with the optional aid of authorized 
individuals, generate a Media UID 54, Media Key 52, 

55 and Access Vector 60 for use of the media 302. At the 
end of this process, the Media UID 54, Media Key 52, 
User UID 56, and Access Vector 60 are archived 
together at the Crypto Support Center 310 and stored 
temporarily in Local Crypto Support Device 320. 
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Local Crypto Support Device 320 then writes the 
Media UID 54 to an appropriate location on Media 302 
(e.g.. Volume Label). It combines the User UID 56, 
Enclave Key 50, and PIN 58 to form a key with which it 
enciphers the Media Key/ Access Vector pair 62. it uses 
the Media UID 54 to index storage 332 of Personal Key- 
ing Device 330 and stores the enciphered pair 62 in the 
appropriate location. 

At this point, the initialization is complete. Media 
302 can be identified and the individual's Personal Key- 
ing Device 330 contains a Media Key 52 which can only 
be used by an individual who has physical possession 
of that Personal Keying Device 330, knows that individ- 
ual's PIN 50, and has Media 302 controlled by a Crypto 
Media Controller 342, containing the Enclave Key. 

Keying of Devices 

An individual establishes a data transfer interface 
between his or her Personal Keying Device 330 and any 
Crypto Media Controller 342 containing the Enclave 
Key, and between that Crypto Media Controller 342 and 
the Media 302 the individual desires to access. If the 
media 302 is removable, this will involve placing the unit 
of media 302 into the appropriate device (e.g. diskette 
drive) or the Workstation 340. From this point on, the 
alternate embodiment 300 operates in the same man- 
ner as the first described Data Enclave embodiment 20, 
as set forth in Steps 1 -10 under the heading "Keying of 
Devices." 

Key Assignment for Already Initialized Media 

Key assignment is performed in substantially the 
same fashion as Media Initialization and Key Genera- 
tion, insofar as the configuration and interaction of the 
Personal Keying Device 330, Workstation 340, Local 
Crypto Support Device 330 and Support Center 310 
interact to generate a Media Key/Access Vector pair 91 
for the already initialized media 302 by reference to the 
archived Media Key 42 for the media. 

The present invention is to be limited only in accord- 
ance with the scope of the appended claims, since oth- 
ers skilled in the art may devise other embodiments still 
within the limits of the claims. The above-described 
detailed architectures are not meant to be limiting, and 
other equivalent forms may be substituted if desired. 

Claims 

1 . In a computing system having a security server and 
a controller which can communicate with the secu- 
rity server, a method of identifying and authenticat- 
ing a first user from a plurality of users seeking 
access to the security server, wherein the method 
comprises the steps of: 

providing a cryptographic key; 



assigning a user unique identifier to each user, 
wherein the step of assigning comprises 
assigning a first user unique identifier to the 
first user; 

5 assigning a personal keying device to each 

user, wherein each personal keying device 
comprises input means for entering user input 
and storage means for storing an encrypted 
last countersign and an encrypted version of 

to the user unique identifier of the user to whom 

the personal keying device is assigned; 
storing, in the security server, an expected per- 
sonal identification number associated with the 
first user unique identifier; 

is attaching the personal keying device assigned 

to the first user to the controller; 
entering, at the input means of the personal 
keying device, a user-entered personal identifi- 
cation number; 

20 combining the user-entered personal identifica- 

tion number, the first user unique identifier and 
the last countersign into a message; 
encrypting the message with the cryptographic 
key and transmitting the encrypted message to 

25 the security server; 

decrypting the message and comparing the 
user-entered personal identification number to 
the expected personal identification number; 
if the user-entered personal identification 

30 number matches the expected personal identi- 

fication number, comparing the decrypted last 
countersign to a stored value to determine the 
first user's access rights. 

35 2. A method according to claim 1 wherein the step of 
providing a cryptographic key comprises the steps 
of: 

forming a data enclave; and 
40 using an enclave key as the cryptographic key. 

3. A computing system comprising a security server 
and a controller which can communicate with the 
security server, and a plurality of users seeking 
45 access to the security server, a method of control- 
ling access by a plurality of users including a first 
user, to privileged operations, wherein the method 
comprises the steps of: 

so providing a cryptographic key; 

assigning a user unique identifier to each user, 
wherein the step of assigning comprises 
assigning a first user unique identifier to the 
first user; 

55 assigning a personal keying device to each 

user, wherein each personal keying device 
comprises input means for entering user input 
and storage means for storing an encrypted 
last countersign and an encrypted version of 
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the user unique identifier of the user to whom 

the personal keying device is assigned; 

attaching the personal keying device assigned 

to the first user to the controller; 

identifying and authenticating the first user to 5 

the security server; 

invoking an attention signal; 

combining the attention signal and the first user 

unique identifier into a message; 

encrypting the message with the cryptographic 10 

key and transmitting the encrypted message to 

the security server; 

decrypting the message and determining, from 
the first user unique identifier, privileges 
granted to the first user; /5 
determining a new countersign; 
encrypting the new countersign with the crypto- 
graphic key and transmitting the new counter- 
sign to the controller; and 

decrypting the new countersign and displaying 20 
the decrypted new countersign to the first user. 

4. A method according to claim 3, wherein the step of 
identifying and authenticating the first user com- 
prises the steps of: 25 

storing, in the security server, an expected per- 
sonal identification number associated with the 
first user unique identifier; 

entering, at the input means of the personal 30 
keying device, a user-entered personal identifi- 
cation number; 

combining the user-entered personal identifica- 
tion number, the first user unique identifier and 
the last countersign into a message; 35 
encrypting the message with the cryptographic 
key and transmitting the encrypted message to 
the security server; 

decrypting the message and comparing the 
user-entered personal identification number to 40 
the expected personal identification number; 
if the user-entered personal identification 
number matches the expected personal identi- 7. 
fication number, comparing the decrypted last 
countersign to a stored value to determine the 45 
first user's access rights. 

5. A method according to claim 4, wherein the step of 
providing a cryptographic key comprises the steps 

<* 50 

forming a data enclave; and 

using an enclave key as the cryptographic key. 

6. A trusted path system for securing computing trans- 55 
actions by a user, the system comprising: 

a secure computer, wherein the secure compu- 
ter comprises: 



a logic and control unit; 

a cryptographic unit connected to the logic and 
control unit; 

a communication unit connected to the logic 
and control unit; 

storage means for storing a plurality of crypto- 
graphic keys, a user unique identifier and a last 
authentication token; and 
an authentication token generator for generat- 
ing a new authentication token; 
an untrusted communications system con- 
nected to the communication unit of the secure 
computer; 

a workstation which communicates through the 
untrusted communications system to the 
secure computer, wherein the workstation 
comprises: 

a logic and control unit; 

a communication unit connected to the logic 
and control unit; and 

storage means for storing a workstation identi- 
fier; and 

a personal unit which communicates to the 
workstation, wherein the personal unit com- 
prises: 

a logic and control unit; 

a cryptographic unit, connected to the logic and 
control unit, which encrypts and decrypts mes- 
sages passed between the personal unit and 
the security server; 

a keyboard connected to the logic and control 
unit; 

a display connected to the logic and control 
unit; 

a communication unit, connected to the logic 
and control unit, for communicating with the 
communication unit of the workstation; and 
storage means for storing the user unique iden- 
tifier, the last authentication token and one or 
more cryptographic keys from the plurality of 
cryptographic keys. 

A trusted path system for communication between 
a workstation and a secure computer over an 
untrusted communication medium, comprising: 

a logic and control unit in the workstation and in 
the secure computer; 

an end-to-end authentication token exchange 
protocol used to assure the logic and control 
unit in the workstation is communicating with 
an authentic logic and control unit in the secure 
computer, and vice versa; 
the token exchange protocol operating by 
chaining transactions together so that a forged 
transaction entered into the interaction 
between workstation and secure computer is 
detected the very next time a legitimate trans- 
action is received by a logic and control unit; 



26 



51 EP 0 737 907 A2 

a cryptographic checksum protocol used to 
assure transactions between the logic and con- 
trol units have not been tampered with, the 
checksum protocol authenticating single trans- 
actions between the workstation and the 5 
secure computer rather than sequences of 
transaction; and 

an identification and authentication protocol 
invoked when a user wishes to interact with the 
secure computer for some period of time, using 10 
the keyboard and displaying of the workstation 
and the untrusted communications medium, 
the period of interaction being a session, and 
the act of initiating a session called logon, and 
that of terminating one is called logout. 15 
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